W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2016

[csswg-drafts] [css-inline] spec should define behavior when 'initial-letter' and 'float' both set on same element/pseudo-element

From: L. David Baron via GitHub <sysbot+gh@w3.org>
Date: Mon, 07 Nov 2016 06:39:03 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-187635900-1478500740-sysbot+gh@w3.org>
dbaron has just created a new issue for 

== [css-inline] spec should define behavior when 'initial-letter' and 
'float' both set on same element/pseudo-element ==
The definition of [initial letter 
should specify what happens when <code>float</code> and 
<code>initial-letter</code> are set on the same element.

Prior to the introduction of initial letter styling, CSS had two types
 of </code>::first-letter</code> pseudo-elements:  (1) regular inlines
 and (2) floats.  Now (3) <code>initial-letter</code> creates a third,
 but I think it should be creating only one more and not two.  In 
particular, I don't think there should be two different types of 
initial letter.  (The spec certainly doesn't describe two such types.)

Then there's the question of, given code like:
p::first-letter {
  float: left;
  initial-letter: 3 3;
which one wins.  That is, do we create a type (2) pseudo-element or a 
type (3) one.

I tend to think that if we want to allow authors to use various 
graceful degradation strategies (although they could do more with 
<code>@supports</code>, I suppose) it's probably better for the newer 
feature to override the older one, i.e., for the above case to result 
in the <code>float: left</code> being ignored.

Either way, this should be explicitly specified.

And I think that explicit specification should *probably* result in 
the computed value that is ignored being changed, although I haven't 
thought through the details of this at all.

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/688 using your GitHub 
Received on Monday, 7 November 2016 06:39:09 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:05 UTC