Re: [css-ui] css-counter-styles or outline

> On Jan 15, 2018, at 10:55, Florian Rivoal <florian@rivoal.net> wrote:
> 
> 
>> On Jan 15, 2018, at 4:53, Dennis Heuer <einz@verschwendbare-verweise.seinswende.de> wrote:
>> 
>> Hello,
>> 
>> At first:
>> 
>> "GitHub Issues are preferred for discussion of this specification. When
>> filing an issue, please put the text “css-counter-styles” in the title,
>> preferably like this: “[css-ui] …summary of comment…”. All issues and
>> comments are archived, and there is also a historical archive."
>> 
>> Please name the archive
> 
> There is a link to the archive in the text you quoted. This is
> considered a good way to find it.
> 
>> and give a hint to the mailinglist and that you
>> read it! (Not everyone wants accounts everywhere in the world,
>> definitely not for what can be said in a short email.)
> 
> This group deals with a very high volume of issues. We used to take
> them in by email, and found that it was very hard to keep track of
> everything, and that some comments got lost. We have decided to
> use github as our primary system for taking in comments. That doesn't
> mean github is the perfect system, but we need to have one shared
> worktool to be able to work efficiently, and we picked that one.
> We cannot and will not force anybody to use github if they don't
> like it, and you may use any means you like to try and contact us.
> 
> However, we will not spend time writing explanations for how to contact
> us in ways we do not want to be contacted in.
> 
> Writing to this mailing list is reasonably likely to work, but there is
> also a risk that your comment will be overlooked because this is not
> how we triage and track issues. As I presume you are interested in
> getting your issues addressed, I recommend using github in the future. 
> 
>> It remains unclear how to set the text where (e.g. is title = subject
>> and is summary of comment = css-counter-styles?):
> 
> Github issues, as we request that you file, have a "title" field.
> This is where you should write the title.
> 
> A summary of your comment means just that: you summarize what you are
> writing about. If you think for example that there is a problem in the
> grammar of the outline property, you would write "[css-ui] problem with
> the grammar of the outline property", and then give details in the body
> issue.
> 
> 
>> ------------------
>> 
>> I already wrote this to the border-guys from whom you seem to inherit
>> rules
>> 
>> Your spec specifies that the outline-width is medium and the
>> outline-style is none. This causes the (unneccessary) extra
>> convention:
>> 
>> "Computed value: absolute length; 0 if the outline style is none."
>> 
>> In contrast, the property text-decoration-style defaults to solid, and
>> the property text-decoration-line defaults to none. This is far more
>> sane in two ways:
>> 
>> 1) No neccessity for the above extra convention
>> 
>> 2) The 'on/off-switch' for the decoration line is the line property
>> instead of the style property, which is far more logical from my point
>> of view. Because text-decoration-color is initially currentcolor,
>> setting text-decoration-line to, say, underline gives a nice default
>> underline of solid style in text color. That is good! I'd want this for
>> outline as well! (Even though we can argue that the initial value for
>> outline-color should be red.) Specify the initial value for width as
>> none, the initial value for style as solid and the initial value for
>> color as currentcolor and switching width to medium gives a nice
>> default outline!
>> 
>> 3) style:none is now a redundant value and might be dropped
> 
> Regardless of the merits of your proposal, it is not practical to consider
> changing how multicolumn works at this point. This specification has existed
> for many years, has been implemented by browsers for many years, and has been
> used on the web for many years.
> 
> This is very often a concern we have to deal with: changing specifications
> in ways that would cause existing content to display differently would
> cause lost of web sites to fail, and therefore web browsers will refuse to
> make such change, even if it would be a good idea otherwise. We typically
> call that "breaking the web", as in "can we change foo to bar? No, that
> would break the web. Ah, forget it then".
> 
> The changes you suggest fall into that category, so I am afraid this
> suggestion has to be rejected.
> 
> —Florian

Sorry, I mentioned the multicolumn spec in my response,
but your mail was about the css-ui spec. I made this mistake because
you made a similar comment about multicol, and my answers got mixed.
Please accept my apologies.

https://lists.w3.org/Archives/Public/www-style/2018Jan/0039.html

However, the logic of my answer applies to both of your comments.
Both CSS-UI and CSS-MULTICOL have been shipping in their
current form for too long to be able to make this sort of change
without breaking existing content.

—Florian

Received on Monday, 15 January 2018 02:47:23 UTC