discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Pali Rohar <pali.rohar@gmail.com>
Cc: discuss@mandoc.bsd.lv
Subject: Re: Broken tables in HTML output
Date: Mon, 21 Jan 2019 14:16:37 +0100	[thread overview]
Message-ID: <20190121131637.GC77160@athene.usta.de> (raw)
In-Reply-To: <20190121093909.bs3voomg7vonpiah@pali>

Hi Pali,

i'm leaving the complete quotations intact because the context is
important here - even though it is long.

Pali Rohar wrote on Mon, Jan 21, 2019 at 10:39:09AM +0100:
> On Tuesday 04 December 2018 19:04:57 Ingo Schwarze wrote:
>> Pali Rohar wrote on Tue, Dec 04, 2018 at 05:44:14PM +0100:
>>> On Monday 03 December 2018 23:37:43 Ingo Schwarze wrote:
>>>> Pali Rohar wrote on Mon, Dec 03, 2018 at 11:20:45PM +0100:
>>>>> On Monday 03 December 2018 23:14:54 Ingo Schwarze wrote:
>>>>>> Pali Rohar wrote on Mon, Dec 03, 2018 at 11:01:42PM +0100:

>>>>>>> Seems that it is needed to put "border-bottom-style: solid"
>>>>>>> for rowspanned td element.  At least this is working in chrome.

>>>>>> That would further degrade the quality of the HTML code written by
>>>>>> mandoc.  As a rule, "style=" attributes should be avoided and CSS
>>>>>> should instead by used.  Unfortunately, that's not possible here
>>>>>> because the hard-coded presentational decisions like "draw a border
>>>>>> right here" are already contained in the tbl(7) input, and there
>>>>>> is no way to convert those purely presentational decisions of the
>>>>>> author into semantic or structural markup that could be handled
>>>>>> with CSS.
>>>>>> 
>>>>>> But at least the amount of "style=" attributes written should be
>>>>>> minimized.  Only those "style=" attributes should be written that
>>>>>> are required to correctly express the author's intent.

>>>>> This suggestion is to move border style definition from tr do td.

>>>> That would mean writing more "style=" attributes.
>>>> If a row intersects N cells, N times more.
>>>> That is not good.

>>> You can avoid all style= attributes in tables, by declaring class=
>>> attributes instead of them and then in CSS defines border styles for
>>> defined classes.

>> Sure, i could write
>> 
>>   <td class="border-left-double">
>>   <td class="border-bottom">
>>   <td class="border-bottom border-right">
>> 
>> and then in mandoc.css
>> 
>>   .border-left-double { border-left-style: "double"; }
>>   .border-bottom { border-bottom-style: "solid"; }
>>   .border-right { border-right-style: "solid"; }
>> 
>> But is that better than
>> 
>>   <td style="border-left-style: double;">
>>   <td style="border-bottom-style: solid;">
>>   <td style="border-bottom-style: solid; border-right-style: solid;">
>> 
>> and if it is better, why?
>> 
>> It is almost the same amount of attribute text, with only a minor
>> difference in syntax, and it doesn't add any information about
>> meaning or structure.  Also, there is no point for the user to
>> modify ".border-left-double { }" in the stylesheet - what should
>> it be mapped to as a personal style?  Mapping it to, say,
>> 
>>   .border-left-double { border-top-style: solid; }
>> 
>> just wouldn't make sense.  Classes only make sense to me if they
>> tell something about meaning or structure.  If they are merely
>> other names for physical style attributes, they seem pointless
>> to me.  Or am i wrong - and if so, why?

> I was thinking about it... I can say there are two arguments why
> to use classes instead of inline style=.
> 
> 1) Separate style logic (semantics) outside of html text (syntax).

In general and in theory, yes.

But that argument does not apply to the specific class attribute
we are discussing: class="border-left-double" would still be
specifying styling and not semantics.  It would abuse the class=
attribute for physical styling.  Using class= (which is *supposed*
to be semantic, but wouldn't be semantic in this case) does not
make "border-left-double" a statement about logic; "border-left-double"
remains a styling instruction no matter what.

It can't be helped because the document author specified the physical
styling, without stating for which logical reasons it was chosen.

> 2) Ability to correctly set style via custom css file.
>    If somebody wants to use custom css file, then inlined style=
>    attributes can cause problems.

In general and in theory, yes.

But that argument does not apply to the case at hand.  Suppose i would
put a class="border-left-double" attribute in there, and the user
wanted to do CSS customization.  Then all they can do is, say,
replace all left double borders with top dotted borders, or something
like that.  Customization just doesn't make sense to me in this case.

> With <td style="..."> you are saying use this specific style. But with
> <td class="..."> you are saying that it belongs to specific class and
> make abstraction how styles are used. For me it looks like a "proper"
> way how to implement different things, by usage of layering abstraction.

In general and in theory, yes.

But in the specific case, i see no practical advantage whatsoever,
and abusing class= for physical styling seems even worse to me than
at least being honest and admitting that we have to do hard-coded
styling because that's what the document author requested, and because
we don't have the slightest idea what the intended *menaing* of these
borders might be.

Or what am i missing?

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

  reply	other threads:[~2019-01-21 13:16 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-16 11:03 Pali Rohár
2018-07-16 15:29 ` Ingo Schwarze
2018-07-16 16:36   ` Pali Rohár
2018-07-16 17:44     ` Ingo Schwarze
2018-11-24 23:15   ` Ingo Schwarze
2018-11-25 19:34   ` Ingo Schwarze
2018-11-25 21:25     ` Ingo Schwarze
2018-11-26  8:53       ` Pali Rohár
2018-11-26 21:27   ` Ingo Schwarze
2018-11-26 21:58     ` Pali Rohár
2018-11-26 22:01       ` Pali Rohár
2018-11-26 22:05         ` Pali Rohár
2018-12-01 17:20           ` Ingo Schwarze
2018-12-01 19:35             ` Pali Rohár
2018-12-03 20:46             ` Pali Rohár
2018-12-04  5:33               ` Ingo Schwarze
2018-12-03 22:01             ` Pali Rohár
2018-12-03 22:14               ` Ingo Schwarze
2018-12-03 22:20                 ` Pali Rohár
2018-12-03 22:37                   ` Ingo Schwarze
2018-12-04 16:44                     ` Pali Rohár
2018-12-04 18:04                       ` Ingo Schwarze
2019-01-21  9:39                         ` Pali Rohár
2019-01-21 13:16                           ` Ingo Schwarze [this message]
2018-11-29  2:15     ` Ingo Schwarze

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190121131637.GC77160@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=discuss@mandoc.bsd.lv \
    --cc=pali.rohar@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).