From: L. David Baron (dbaron@fas.harvard.edu)
Date: 1999-03-27
Archive: http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html
This message addresses two issues. The first is a problem where the top and bottom values of CSS's 'vertical-align' lead to unsolvable situations, if their current wording is taken literally. The second is a possible solution to the problem of indeterminate situations with 'top' and 'bottom'. At the end, I try to explain how whole thing works (that is, my interpretation of the spec, which I think is somewhat unclear, but does define how things should work in detail). First, some definitions needed for any complete definition of the top and bottom values. Some of these definitions are rather arbitrary, and I'm just defining them so I don't have to repeat the same ten word phrases. root of the line: the anonymous inline element that surrounds the entire line, as I proposed in [1]. There has to be some notion of this, or else many things don't make sense. loose: has vertical-align = top or vertical-align = bottom or is the root of the line anchored (to parent): not loose. Every anchored element has a specified vertical position relative to its parent element. If its parent moves, it does too. anchored (to arbitrary ancestor): A descendant Z is anchored to an ancestor A if Z is not loose and none of the ancestors of Z that are also descendents of A are loose. full top: The full top of an element is the top of the anchored descendent (or the element itself) whose top is highest. full bottom: same thing, reversed full height: the distance from the full top to the full bottom (I don't like the terms "full bottom" and "full top." "Full height" came first.) Note that the top and bottom here refer to the box created by the line-height (the "logical box"). The box described by font-size, padding, and border is not really the element's box, but could be called its "visual box." unsolvable cases ---------------- Unsolvable situations arise if a loose element that has vertical-align: bottom has descendants anchored to it that extend below its bottom or if an element with vertical-align: top has descendants anchored to it that extend above its top. When this is true, the bottom of the element cannot touch the bottom of the line box as required by the definition of bottom (top is analogous): Align the bottom of the box with the bottom of the line box. [2] ( This would not be a problem if the elements within it that protrude out of the line. This would make the bottom of the line no longer the bottom of the lowest element, as required by [3]: The line box height is the distance between the uppermost box top and the lowermost box bottom. ) Thus I think the definition of top [2] should be changed to read: Align the full bottom of the box with the bottom of the line box. and top should be changed analogously. a solution for indeterminate cases ---------------------------------- (This assumes that Eric is right about what he said earlier today and that an element can be top aligned with itself. It never occurred to me that it couldn't. It has to be allowed.) CSS does not fully describe the result if the tallest (in full height) loose element in the line is not the root of the line. This is what I mean by an indeterminate case. There are a number of ways one could make a rule so that this is not indeterminate. I think the best would be to treat the largest element (in full height) as the root of the line (that is, to place it first), and place the root element of the line as if it had the alignment of the largest loose element (which is either top or bottom). an algorithm for computing line height and alignment ---------------------------------------------------- This is basically a rewrite of a message I wrote in private email, but I think it will help to understand what I said above. It is how I think line heights should be calculated on the whole. The whole thing depends on my first proposal (unsolvable cases), but only part of rule 3 depends on my second proposal (indeterminate cases). 1) Find the "full height" of the outermost element in the line and all the "loose" elements within it. This is done using the line height and vertical alignment of all the attached children of each loose element. 2) Determine the tallest (in full height) loose element in the line and place it so its full top is even with the top of the space available for the line (this is either the bottom of the previous line box or the content edge of a block-level element). The top of this element is the top of the line box, and the bottom of this element is the bottom of the line box. 3) Place all other loose elements so their full top or full bottom (depending on their vertical-align value) even with the top or bottom of the line box. If the tallest loose element in the line is not the root of the line, then place the root of the line as if its 'vertical-align' were the same as that of the tallest loose element. David [1] http://lists.w3.org/Archives/Public/www-style/1999Jan/0027.html [2] http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-vertical-align [3] http://www.w3.org/TR/REC-CSS2/visudet.html#line-height ----------------------------------------------------------------- L. David Baron Freshman, Harvard dbaron@fas.harvard.edu Links, SatPix, CSS, etc. < http://www.fas.harvard.edu/~dbaron/ > WSP CSS AC < http://www.webstandards.org/css/ >
From: fantasai (fantasai@escape.com)
Date: 2000-05-04
Archive: http://lists.w3.org/Archives/Public/www-style/2000May/0010.html
That does make a lot more sense. :) Sorry for the inane question.
(Recap) So with
<P> Section 1: Here is some text. <SPAN style="display:
run-in">run-in</SPAN> Section 2: Here's the rest of the paragraph.</P>
We get this:
,----------------------------------.
|Section 1: Here is some text. |
`----------------------------------'
,----------------------------------.
|run-in |
`----------------------------------'
,----------------------------------.
|Section 2: Here's the rest of the |
|paragraph. |
`----------------------------------'
That's just fine, but it's not really a run-in. *Current definitions
aside*, wouldn't this better reflect the purpose of a run-in display?
,----------------------------------.
|Section 1: Here is some text. |
`----------------------------------'
,----------------------------------.
|[run-in] Section 2: Here's the |
|rest of the paragraph. |
`----------------------------------'
Here the run-in becomes the first inline of the following block.
The block just happens to be the anonymous block created as a
result of the run-in.
Changing a run-in to a block before an inline probably has /some/ reason
behind it, but I can't think of any (or find any, for that matter--I did
run a search on this list).
From: fantasai (fantasai@escape.com)
Date: 2003-03-02
Archive: http://lists.w3.org/Archives/Public/www-style/2003Mar/0013.html
CSS2.1 draft, Section 12.2 http://www.w3.org/TR/2003/WD-CSS21-20030128/generate.html#content # normal # On the :before and :after pseudo-elements, # this value is the same as 'none'. # none # No content is generated. The 'none' value is redundant; please take it out. If it's needed in CSS3, it can be added there--no need to confuse the issue. 'normal' should be defined as follows: The pseudo-element is not rendered. It should also be renamed to 'auto', as 'auto' means "self"-- which is a connotation you'll want in CSS3. It also means "automatic"; the content and behavior associated with the element is "automatic" instead of manually specified in the style rule. In contrast, 'normal' here means little more than 'default', and it implies that any other value is "abnormal". ;) If the WG still feels 'normal' is more appropriate than 'auto', I would *really* like to know why. *formally requests a reply* ~fantasai
From: staffan.mahlen@comhem.se
Date: 2003-09-17
Archive: http://lists.w3.org/Archives/Public/www-style/2003Sep/0096.html
Hi, The new descriptions in the lastest WD on those things helped me a lot, good work. http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q15 The new first paragraph in block formatting context is good and makes me think i understand the questions i had on floats earlier. However, i think an example or two would be helpful to more clearly show for instance how an element that generates a new block formatting context affects its containing blocks size when the containing block also generates a new block formatting context (is this described somewhere else? I failed to find it if so). I also think some kind of more explicit pointer to this effect should be supplied in the calculating widths/heights sections (or is the effect seen more as an implicit min-width/min-height?). Something i dont understand is why non-initial overflow needs to generate a new block formatting context? http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats The new paragraph on how the margin box of a block that generates a new block formatting context interacts with floats in the same block context is helpful, but i think perhaps the effect of a float nested inside an element wich generates a new block formatting context along with more examples would help even further (eg a float in a table cell). The way things in the draft are currently written the example under the paragraph probably belongs to the previous paragraph, which could be a bit confusing. The paragraph is a little vague on how to handle the conflict between a float and another block that generates a new block formatting context when they are in the same block formatting context. Why not require that the box is cleared? When is it desirable to position it adjacent, creating a kind of a "pseudo-float"? As an editorial comment i noticed that the phrase "block formatting context" was only occationally linked to its defintion, in case this is not intentional. /Staffan
From: staffan.mahlen@comhem.se
Date: 2003-09-17
Archive: http://www.w3.org/mid/3F684CB4.21220.7532AF@localhost
Hi, The new descriptions in the lastest WD on those things helped me a lot, good work. http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q15 The new first paragraph in block formatting context is good and makes me think i understand the questions i had on floats earlier. However, i think an example or two would be helpful to more clearly show for instance how an element that generates a new block formatting context affects its containing blocks size when the containing block also generates a new block formatting context (is this described somewhere else? I failed to find it if so). I also think some kind of more explicit pointer to this effect should be supplied in the calculating widths/heights sections (or is the effect seen more as an implicit min-width/min-height?). Something i dont understand is why non-initial overflow needs to generate a new block formatting context? http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats The new paragraph on how the margin box of a block that generates a new block formatting context interacts with floats in the same block context is helpful, but i think perhaps the effect of a float nested inside an element wich generates a new block formatting context along with more examples would help even further (eg a float in a table cell). The way things in the draft are currently written the example under the paragraph probably belongs to the previous paragraph, which could be a bit confusing. The paragraph is a little vague on how to handle the conflict between a float and another block that generates a new block formatting context when they are in the same block formatting context. Why not require that the box is cleared? When is it desirable to position it adjacent, creating a kind of a "pseudo-float"? As an editorial comment i noticed that the phrase "block formatting context" was only occationally linked to its defintion, in case this is not intentional. /Staffan
From: Ian Hickson (ian@hixie.ch)
Date: 2003-09-22
Archive: http://lists.w3.org/Archives/Public/www-style/2003Sep/0106.html
On Mon, 22 Sep 2003, Bjoern Hoehrmann wrote: > > I think the Candiate Recommendation Exit Criteria listed in the > CSS 2.1 Last Call Working Draft "violate" the W3C Process Document. > > It states that features may get dropped under certain circumstances but > it does not identify which features are considered at risk. The Process > Document requires to identify such features, otherwise the document > would be put back to the Working Group for further work if features are > dropped. This probably not intended by the statement. Going back to Last Call with an updated document is actually what I would prefer. Any feature we remove is likely to cause big changes to the document and we really should have a solid revew period for that. -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2003-09-28
Archive: http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
-- Section 5.5 (Descendant Selectors)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#descendant-selectors>
This says, in the example:
"the whitespace is the descendant selector indicating..."
The whitespace is a combinator which makes the whole selector a descendant
selector, no? Which is not what that's saying...
-- Section 5.10 (Pseudo-elements and pseudo-classes)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#pseudo-elements>
Why are "Conforming HTML UAs" exempted from :first-line and :first-letter?
There seems to be no good reason for this.
-- Section 5.11.1 (:first-child pseudo-class)
<http://www.w3.org/Style/css2-updates/WD-CSS21-20030915-diff/selector.html#first-child>
This needs to define what a "first child" is. From what I can tell, the intent
is to match elements that would match both the "* > *" and "* + *" selectors.
In particular, the <span> in both examples below would match :first-child:
<p>This is a <span>test.</span></p>
<p><!-- Of the emergency --> broadcast system</p>
Perhaps something like, "The :first-child pseudo-class matches an element node
that is the first element node in the child node list of some other element
node"?
-- Section 5.11.3 (The dynamic pseudo-classes: :hover, :active, and :focus)
<http://www.w3.org/Style/css2-updates/WD-CSS21-20030915-diff/selector.html#dynamic-pseudo-classes>
If an element is hovered, are its ancestors considered hovered? Is this
UA-dependent, or should it be specified?
The example used is somewhat unfortunate because it encourages using selectors
like "a:hover" which don't do quite what page authors expect based on this
example (in particular, "a:hover" applies to named anchors, while ":link" and
":visited") do not. I'm not sure how one could replace this example while
still illustrating the order-dependence, though....
-- Section 5.12.2 (The :first-letter pseudo-element)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-letter>
'float' is not listed as a propety that applies to :first-letter
pseudo-elements. An editing error?
-- Section 5.12.2 (The :first-letter pseudo-element)
The last paragraph of the example with the floated 'T' says:
Note that the :first-letter pseudo-element tags abut the content (i.e., the
initial character), while the :first-line pseudo-element start tag is
inserted right after the start tag of the element to which it is attached.
I'm not sure what this means, in light of the example for :first-line, in which
we get the fictional tag sequence: <div><p><div:first-line><p:first-line> ...
This section should also make it clear that given markup like:
<div>
<p>
Some text
more text
</p>
</div>
with the linebreak occurring where I show it, the fictional tag sequence is:
<div><p>
<div:first-line><p:first-line>
<div:first-letter><p:first-letter>S</p:first-letter></div:first-letter>omeText
</div:first-line></p:first-line>
more text
</p></div>
because right now, it only makes clear the interaction of first-letter and
first-line when both are set on the same element, and does not specify the
ordering of p:first-line and div:first-letter in the above example.
Boris
--
"What the hell are you getting so upset about? I
thought you didn't believe in God."
"I don't," she sobbed, bursting violently into
tears, "but the God I don't believe in is a good God, a
just God, a merciful God. He's not the mean and stupid
God you make Him out to be."
--Joseph Heller, "Catch-22"
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2003-09-28
Archive: http://lists.w3.org/Archives/Public/www-style/2003Sep/0134.html
-- Section 1.4.2, "Applies To" paragraph <http://www.w3.org/TR/2003/WD-CSS21-20030915/about.html#applies-to>
This should probably say "elements with display:table" instead of "table
elements" (since the latter typically means "elements with a tag name of
'table'").
-- Section 1.4.5 <http://www.w3.org/TR/2003/WD-CSS21-20030915/about.html#q16>
"after" may be better than "to the right". For example, in aural rendering,
this would be the case....
I can't check how this actually renders in various UAs because a quick look at
the section of the specification with the most images (Chapter 9) doesn't show
any images provided with a long description link as described... (and none have
a "longdesc" attribute).
-- Section 1.5 <http://www.w3.org/TR/2003/WD-CSS21-20030915/about.html#q17>
You can't very well say "both" about three people. ;)
Boris
--
"What the hell are you getting so upset about? I
thought you didn't believe in God."
"I don't," she sobbed, bursting violently into
tears, "but the God I don't believe in is a good God, a
just God, a merciful God. He's not the mean and stupid
God you make Him out to be."
--Joseph Heller, "Catch-22"
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2003-09-28
Archive: http://www.w3.org/mid/200309282304.h8SN40r2004872@nerd-xing.mit.edu
-- Section 6.4.3 (Calculating a selector's specificity)
The spec says:
li:first-line {} /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,2 */
It should say d=2 here.
-- Section 6.4.4 (Precedence of non-CSS presentational hints)
Why is "dir" not considered a presentational hint?
"type" is not presentational in some cases, but presentational in others (on
<ol>, <ul>, <li>, to be precise).
Boris
--
"What the hell are you getting so upset about? I
thought you didn't believe in God."
"I don't," she sobbed, bursting violently into
tears, "but the God I don't believe in is a good God, a
just God, a merciful God. He's not the mean and stupid
God you make Him out to be."
--Joseph Heller, "Catch-22"
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2003-09-28
Archive: http://www.w3.org/mid/200309282315.h8SNFiEh006969@nerd-xing.mit.edu
-- Section 7.3 (Recognized media types)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/media.html#media-types>
What does "The names of media types are normative" mean? What should a UA do
when encountering an @media or @import rule that lists an unknown media type?
E.g.
@media screen, boomerang {
....
}
Boris
--
"What the hell are you getting so upset about? I
thought you didn't believe in God."
"I don't," she sobbed, bursting violently into
tears, "but the God I don't believe in is a good God, a
just God, a merciful God. He's not the mean and stupid
God you make Him out to be."
--Joseph Heller, "Catch-22"
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2003-09-28
Archive: http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
-- Section 4.1.1
<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#tokenization>
Is it intended that '_' be a valid "ident" production? At the moment it is. So is
'-_', for that matter. Perhaps the "ident" production should be defined as:
ident [-_]?{nmstart}{nmchar}
and the "nmstart" definition retained as it was in CSS2
([a-zA-Z]|{nonascii}|{escape}) ? No strong feelings either way here, it's just
that the current proposal seems a bit odd.
-- Section 4.1.1
<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#tokenization>
Definition of the "unicode" production does not match Appendix G.
-- Section 4.1.1
<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#tokenization>
Is there a reason that CDO and CDC are allowed at all places in the stylesheet
between rules? This seems to complicate parsing unnecessarily. Is it desired
that CDO/CDC be allowed in linked stylesheets? They would seem very out of
place there.... Perhaps I am misunderstanding what this is actually saying; if
so, perhaps an informative note is in order to clarify the situation?
-- Section 4.3.4
<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#uri>
The text:
Parentheses, commas, whitespace characters, single quotes (') and
double quotes (") appearing in a URI must be escaped with a
backslash: '\(', '\)', '\,'.
is misleading, since they in fact do not have to be escaped if the URI string
is in quotes. Also, it is not immediately clear to me why commas are included
in the list. Is there a reason.
-- Section 4.3.4
<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#uri>
What happens if the URI string is not a syntactically valid URI? For example:
url(http:/www.example.com/)
or something along those lines? Does this affect the parsing or style
computation phase, or is this handled only when the resource actually needs to
be loaded, thus falling under the "User agents may vary" clause at the end of
the section?
-- Section 4.3.7
<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#strings>
The language
Double quotes cannot occur inside double quotes, unless escaped (as '\"' or
as '\22').
is somewhat misleading, since there are other ways that a quote could be
escaped (eg using \000022). Perhaps an "e.g.," at the beginning of the
parenthetical remark is in order? Same for single quotes.
-- Section 4.4
<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q23>
What about stylesheets that have a BOM but no @charset rule? Should the
presence of a BOM imply that the sheet is encoded as, eg UTF-8 or UTF-16LE (if
the appropriate BOM is present), as it does for XML?
Another point is that it's trivial to have a stylesheet for which steps 1, 2, 3
will give no useful charset value. In fact, the vast majority of stylesheets
currently on the web fall into this category. Is the behavior UA-dependent in
that case? If so, this should be explicitly stated, I think. Personally, I
think it would be worthwhile to specify behavior in that eventuality.
Boris
--
"What the hell are you getting so upset about? I
thought you didn't believe in God."
"I don't," she sobbed, bursting violently into
tears, "but the God I don't believe in is a good God, a
just God, a merciful God. He's not the mean and stupid
God you make Him out to be."
--Joseph Heller, "Catch-22"
From: L. David Baron (dbaron@dbaron.org)
Date: 2003-09-29
Archive: http://www.w3.org/mid/20030929175350.GA4936@darby.dbaron.org
On Monday 2003-09-29 13:29 -0400, Chris Moschini wrote:
>
> In the CSS2.1 Default HTML Style sheet:
>
> http://www.w3.org/TR/CSS21/sample.html
>
> It still says that CSS2.1 cannot fully express the presentation
> of elements like img and frame. Yet CSS3 can, like so:
>
> img, object, applet, embed, iframe, frame, frameset
> {
> display:inline-block;
> }
That doesn't fully describe the presentation, since it doesn't say what
the replaced content is. Doing that requires CSS3.
> http://www.w3.org/TR/2003/WD-css3-ui-20030703/#qA
>
> With the introduction of inline-block to CSS2.1, it can in fact
> fully define all these elements' presentation. This and several
The addition of 'inline-block' doesn't change *anything* for replaced
elements, since the rules for inline and inline-block replaced elements
are exactly the same. ('inline-block' allows non-replaced elements to
act like inline replaced elements.)
-David
--
L. David Baron <URL: http://dbaron.org/ >
From: Chris Moschini (cmoschini@myrealbox.com)
Date: 2003-09-29
Archive: http://www.w3.org/mid/1064856561.a6c4b580cmoschini@myrealbox.com
In the CSS2.1 Default HTML Style sheet:
http://www.w3.org/TR/CSS21/sample.html
It still says that CSS2.1 cannot fully express the presentation
of elements like img and frame. Yet CSS3 can, like so:
img, object, applet, embed, iframe, frame, frameset
{
display:inline-block;
}
http://www.w3.org/TR/2003/WD-css3-ui-20030703/#qA
With the introduction of inline-block to CSS2.1, it can in fact
fully define all these elements' presentation. This and several
other sections of the sample stylesheet need to be updated to
reflect this newly available value in CSS2.1.
-Chris "SoopahMan" Moschini
http://hiveminds.info/
http://soopahman.com/
From: Jukka K. Korpela (jkorpela@cs.tut.fi)
Date: 2003-10-01
Archive: http://www.w3.org/mid/Pine.GSO.4.58.0310012037070.20874@korppi.cs.tut.fi
On Wed, 1 Oct 2003, Boris Zbarsky wrote: > <span style="text-decoration: underline">2<sup>2</sup> = 4</span> > > What should be underlined, and how? Notice the difference between the CSS21 > proposal and just inheriting the text-decoration in this case. Neither the behavior specified nor the common browser behavior (which effectively corresponds to inheritance) is generally suitable. While a continuous underline would be OK in this case, what about <span style="text-decoration: underline">a<sub>0</sub></span> which would have the subscript crossed by the underline? Assuming that the underline position is roughly the same as used by present-day browsers, of course. The text-decoration property as a whole is questionable. It should probably be preserved for compatibility reasons, but its name is heavily misleading, and most of its values are misleading. The most common value, underline, could and probably should be replaced by a bottom border. So the property should be deprecated, not complicated with new "enhancements". For practical authoring, I have recommended the use of bottom border, rather than text-decoration: underline, for texts that may contain superscripts, subscripts, or other parts that have a baseline different from that of the rest. In fact, it could be better for normal text too, by separating the text better from the horizontal line under it. And I think the specifications don't need any extra functionality, or any changes (from CSS 2.0), for the text-decoration property, except deprecation. Line-though is questionable in most presentation environments, but if it is regarded as useful, something essentially new (like a new property) should be defined. Browsers have already spoiled text-decoration: line-through by implementing it so that the text becomes very hard to read. And authors who use it probably want that, or are at least prepared to that. So any reasonable line-through feature should be named differently. (It should probably be a _light_ and adequately positioned line, so either its presentation should be defined to achieve that, or authors should have tools for setting the line type, color, width, and vertical position.) -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: staffan.mahlen@comhem.se
Date: 2003-10-01
Archive: http://www.w3.org/mid/3F7B235B.20958.28A853@localhost
Hi,
I am a bit puzzled by the...advanced...mechanism on text-decoration
inheritance. Why not just let it be inherited and make it apply to
text nodes only?
The definition currently written seems to be sure to generate
interoperability issues and i cannot see what the advantage for the
author. The average author seems unlikely to assume the behaviour as
written, and should not need to have the in-depth knowledge required
to parse the description to use for instance underline. Even when it
is clearly understood it seems to me that it will be easy to make
errors trying to use it in a nested context.
An example:
<p>Text<img src="dummy.png"/><span>More text</span></p>
When an author sets
p {text-decoration: underline}
img {vertical-align: bottom}
span {display: block}
he will get a line drawn overlapping the image while the text in the
span will not be underlined if i read the rec right. On the other
hand, if he knew to add:
img {float: right}
the image would not be overwritten. I don't think that the way the
definition makes colors of the underline work is very intuitive
either, probably because i see underline and friends as text-features
rather than box properties of the ancestor setting the text-
decoration?
/Staffan
From: staffan.mahlen@comhem.se
Date: 2003-10-01
Archive: http://www.w3.org/mid/3F7B3147.4242.5F08EB@localhost
Hi, I posted on the block formatting context items in CSS21 a while back, and while i do understand that it would take a lot of time to answer every question, i would be very thankful if someone would give me some hints on the following: How do nested and adjacent block formatting contexts interact? My current guess would loosly be something like: A nested block formatting context by default fits into its containing block formatting context forcing the size of the container, overridable by explicit width/height properties on the container. Due to table model restrictions the override case never occurs when the container is display: table-cell. Sibling block formatting contexts are flowed similar to regular blocks, unless they are both floated or both have display: table-cell or both have display: inline-block. Any help much appreciated, /Staffan
From: fantasai (fantasai@escape.com)
Date: 2003-10-01
Archive: http://www.w3.org/mid/3F7B596C.2060902@escape.com
Jukka K. Korpela wrote:
>
> The text-decoration property as a whole is questionable. It should
> probably be preserved for compatibility reasons, but its name is heavily
> misleading, and most of its values are misleading.
Have you looked carefully at CSS3 text?
http://www.w3.org/TR/css3-text/#text-decoration-overview
> The most common value, underline, could and probably should be replaced
> by a bottom border.
Underlining and bottom border are two different effects.
Consider, for example,
:link {
background: aqua;
padding: 0.2em;
text-decoration: underline;
}
:link {
background: aqua;
padding: 0.2em;
border-bottom: solid thin;
}
The line would be drawn close to the text in the first example,
existing *within* the visual box presented by the background.
In the second example, however, the line would extend 0.2em beyond
the text and be positioned that much below it, accenting the bottom
edge of the background-color box in a rather different effect.
> For practical authoring, I have recommended the use of bottom border,
> rather than text-decoration: underline, for texts that may contain
> superscripts, subscripts, or other parts that have a baseline different
> from that of the rest. In fact, it could be better for normal text too, by
> separating the text better from the horizontal line under it.
>
> And I think the specifications don't need any extra functionality, or any
> changes (from CSS 2.0), for the text-decoration property, except
> deprecation.
CSS3's text-underline-position: after-edge; would do a better job of
what you want.
> Line-though is questionable in most presentation environments...
Line-through is provided for effects like *striking out* text that
are marked to be deleted, not for making regular text stand out...
~fantasai
From: Jukka K. Korpela (jkorpela@cs.tut.fi)
Date: 2003-10-02
Archive: http://www.w3.org/mid/Pine.GSO.4.58.0310020923540.11649@korppi.cs.tut.fi
On Wed, 1 Oct 2003, fantasai wrote: > Jukka K. Korpela wrote: > > > > The text-decoration property as a whole is questionable. It should > > probably be preserved for compatibility reasons, but its name is heavily > > misleading, and most of its values are misleading. > > Have you looked carefully at CSS3 text? > http://www.w3.org/TR/css3-text/#text-decoration-overview No really. But the more carefully I read that part of the proposal, the more convinced I am of the point I make above. Extending text-decoration with new features, which might be called real decoration, just adds to the confusion. Actually I had missed that the confusion already started in CSS 2. I had forgotten that, since I've mostly been thinking about those CSS 2 features that actually work. The draft says: "The 'text-decoration' property itself is now a shorthand property for all these new properties. However, the 'text-decoration' values are not composites built from the values of constituent properties. Rather, 'text-decoration' values come from a small set specific to the 'text-decoration' shorthand property." I think there's enough confusion around shorthands. As a whole, they help little, but they create traps even for fairly experienced authors. This would add yet another anomaly to the shorthand trickery. > > The most common value, underline, could and probably should be replaced > > by a bottom border. > > Underlining and bottom border are two different effects. Certainly. But often bottom border is a more suitable effect. What do you need underlining for, anyway, on the Web? Excluding special cases like replicating the appearance of printed text being converted to HTML or XML format, for which <u> markup would actually be more adequate, links are the only thing that should be underlined, due to the history and practices of the Web. Underlining anything else usually just calls for confusion. And for links, a bottom border would generally be better, since it leaves the text more readable when it has descenders or subscripts. OK, most people probably disagree with that. But the point is that underlining has, for better or worse, a well-established limited usage. There's little reason to help authors create confusion by adding variations to the theme. If we wish to allow _decoration_ of texts, that's a different issue. > > Line-though is questionable in most presentation environments... > > Line-through is provided for effects like *striking out* text that > are marked to be deleted, not for making regular text stand out... I would say "marked as deleted". But the point is that if the text is present at all, it should be fairly easily readable, so that the reader can see exactly what has been deleted. And line-through, especially as implemented in browsers, makes the text hard to read. The proposed new properties would help here, but they still don't let you specify the vertical position. I doubt whether all the added complexity is worthwhile. Even if the specification gets approved and implemented in, say, five years (to be optimistic), it will take time before authors learn to use the tuning so that line-through is not too disruptive. And there's the simple option of discourageing the use of line-through and encourageing other approaches in the relatively rare cases where deletions are to be indicated visually. -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2003-10-04
Archive: http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
-- Section 8.1 (Box Dimensions)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#box-dimensions>
The description of "content edge or inner edge" makes it sound like this edge
always surrounds the "rendered content"; the latter term is sort of vaguely
defined. The overall impression given is that given the markup:
<div style="height: 1px">
line<br>
line2
</div>
the "content edge or inner edge" will surround both lines (which is of course
not the case).
I hesitate to suggest a better wording offhand, though... Perhaps "content
area" instead of "rendered content", with a link to a few paragraphs below
where it says "The dimensions of the content area of a box ..."?
-- Section 8.1 (Box Dimensions)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#box-dimensions>
The definition of "box width" given in this section gives me some pause. The
only mentions of the term "box width" in chapters 8-18 of the specification
(other than this definition) are:
A) A statement immediately preceding that says that box widths are explained
in a later chapter.
B) Discussion of percent values for left/right (section 9.3.1 Choosing a
positioning scheme: 'position' property). The prose there says these
are percentages of the "containing block's box width"; is it really intended
that he containing block's margin's affect the offset from the padding edge in
this case, per the definition of "box width"?
C) Discussion of min-width/max-width (10.4 Minimum and maximum widths:
'min-width' and 'max-width'). The prose here says that these properties
constrain "box widths".... except that's not true according to the Section
8.1 definition of "box width". They constrain content widths.
D) A reference to "page box width" in chapter 13. This also seems to want the
content width.
In short, there is no usage of this term in this specification that is
consistent with the definition. I suggest striking the definition and changing
the two uses to refer to content widths, since that seems to be the desired
effect.
The "box height" seems similarly useless.
-- Section 8.2 (Example of margins, padding, and borders)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#mpb-examples>
"The height of each LI box is given by its content height, plus top and bottom
padding, borders, and margins." What does that mean, exactly? That is, what
does "the height of each LI box" in real terms? The exampls does not really
say what this quantity (which is not even well-defined in the presence of
margin collapsing) is used for.
-- Section 8.3.1 (Collapsing margins)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html>
"Collapsing is based on the computed value of 'padding', 'margin', and
'border'."
The computed value of margin properties is "the percentage as specified or the
absolute length". What exactly does it mean for collapsing be based on the
computed value if that can be "the percentage as specified"? Especially if the
collapsing margins belong to boxes with different containing blocks (and hence
different meanings of percentage values)?
-- Section 8.4 (Padding properties: 'padding-top', 'padding-right',
'padding-bottom', 'padding-left', and 'padding')
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#padding-properties>
Unlike margin and border, conforming HTML user agents _do_ have to apply
padding to <html>?
-- Section 8.5.4 (Border shorthand properties: 'border-top', 'border-bottom',
'border-right', 'border-left', and 'border')
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#border-shorthand-properties>
The heading should list top, right, bottom, left in that order, probably.
Boris
--
"What the hell are you getting so upset about? I
thought you didn't believe in God."
"I don't," she sobbed, bursting violently into
tears, "but the God I don't believe in is a good God, a
just God, a merciful God. He's not the mean and stupid
God you make Him out to be."
--Joseph Heller, "Catch-22"
From: fantasai (fantasai@escape.com)
Date: 2003-10-06
Archive: http://www.w3.org/mid/3F81EB3F.5020400@escape.com
Self-Contradiction
==================
These two sentences are in conflict:
S4.1.3 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q6>:
# In CSS 2.1, identifiers... cannot start with a hyphen or a digit.
S4.1.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q4>:
# In CSS2.1, identifiers may begin with '-' (dash) or '_' (underscore).
Terminology
===========
S4.1.7 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q10>:
# A rule set (also called "rule") consists of a selector followed by
# a declaration block.
What you're saying here is that a "rule" is also a "set of rules".
The construct should be either singular /or/ plural, not both at the
same time. Please pick *one*. (And make sure its use is consistent.)
# A declaration-block (also called a {}-block in the following text)
# starts with a left curly brace ({) and ends with the matching right
# curly brace (}).
Is there a particular reason why "declaration-blocks" are not defined in
terms of "blocks" (as defined in the previous section)?
And don't call it a {}-block. @media rules have braces-delimited blocks,
too. Just call it a declaration block. It's a nice, unambiguous term;
there's nothing wrong with it.
Missing Comments
================
S4.1.9<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#comments>:
# CSS also allows the SGML comment delimiters ("<!--" and "-->") in
# certain places, but they do not delimit CSS comments. They are
# permitted so that style rules appearing in an HTML source document
# (in the STYLE element) may be hidden from pre-HTML 3.2 user agents.
# See the HTML 4.0 specification ([HTML40]) for more information.
It says SGML comment delimiters are allowed "in certain places". Very
mysterious-like, especially considering the amount of detail about
HTML. Why not say where exactly?
And why is the definitive CSS document referring to the HTML 4.0 spec
for details about CSS syntax? Or is the "more information" more
information about hiding from pre-HTML 3.2 user agents, not "more
information" about, like, where the comment delimiters may be placed?
Unexpected Errors
=================
S4.2<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#parsing-errors>:
# Malformed declarations. User agents must handle unexpected tokens
# encountered while parsing a declaration by reading until the end
# of the declaration, while observing the rules for matching pairs
# of (), [], {}, "", and '', and correctly handling escapes.
What happens if there's a mismatched bracket?
elem {pro[perty: value; }
or a string with an unescaped newline?
elem {prop: "string }
I can't seem to find "the rules for matching pairs of (), [],
}, "", and ''".
Actual Values
=============
S4.3.2<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#length-units>:
# In cases where the computed length cannot be supported, user agents
# must approximate it in the actual value.
^^^^^^^^^^^^
Actual values haven't been defined at this point. Maybe link to the
appropriate section?
Mismatched Colors
=================
S4.3.6<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#color-units>:
# The format of an RGB value in the functional notation is 'rgb('
# followed by a comma-separated list of three numerical values (either
# three integer values or three percentage values) followed by ')'.
Is rgb(255, 0, 50%) invalid, then?
~fantasai
From: staffan.mahlen@comhem.se
Date: 2003-10-07
Archive: http://www.w3.org/mid/3F833074.32375.922D24@localhost
Hi,
There are differences in how major browsers handle the 'vertical-
align' property.
http://www.w3.org/TR/2003/WD-CSS21-20030915/visudet.html#propdef-
vertical-align
Compared to how 'vertical-align' applies to elements that are
display: table-cell i failed to find an algorithm that specifies how
to perform 'vertical-align' in an inline context.
http://www.w3.org/TR/2003/WD-CSS21-20030915/tables.html#height-layout
An example, assume the below fits on one row horizontally and that
the image is higher than the current line-height:
<img style="vertical-align: top" src="test.png" />Text <img
style="vertical-align: bottom" src="test.png" />
What should be the result and why? If we switch the last to middle,
how does that work (that works the same in all browsers, but i don't
quite understand that it really fits how the CSS 2.1 model states it
should work).
Another question:
http://www.w3.org/TR/2003/WD-CSS21-20030915/visudet.html#propdef-
vertical-align
"top
Align the top of the box with the top of the line box.
bottom
Align the bottom of the box with the bottom of the line box."
Why are they not relative to the parent like the other align
properties?
A testcase:
<span style="vertical-align: top" ><img src="test.png" />in span
</span>text<img src="test.png" />
It seems to me that only one browser makes the first image bleed
upwards, which should be the correct way to render the above
according to the rec i belive?
/Staffan
From: L. David Baron (dbaron@dbaron.org)
Date: 2003-10-07
Archive: http://www.w3.org/mid/20031007195251.GA5491@darby.dbaron.org
On Tuesday 2003-10-07 21:30 +0200, staffan.mahlen@comhem.se wrote: > An example, assume the below fits on one row horizontally and that > the image is higher than the current line-height: > > <img style="vertical-align: top" src="test.png" />Text <img > style="vertical-align: bottom" src="test.png" /> > > What should be the result and why? The correct layout is undefined since (using the terminology in [1]) the tallest loose subtree in the line is not the one established by the root inline box. CSS 2.1 probably should either say this explicitly or define what should happen (perhaps as proposed in the section of [2] on indeterminate cases). > If we switch the last to middle, > how does that work (that works the same in all browsers, but i don't > quite understand that it really fits how the CSS 2.1 model states it > should work). Again using terminology from [1], the tallest loose subtree is now the one established by the root inline box, so the layout is defined. > Another question: > http://www.w3.org/TR/2003/WD-CSS21-20030915/visudet.html#propdef- > vertical-align > "top > Align the top of the box with the top of the line box. > bottom > Align the bottom of the box with the bottom of the line box." > > Why are they not relative to the parent like the other align > properties? Because then they'd be equivalent to 'text-top' and 'text-bottom'? If you're asking why they're there or why anyone would want them, I'm not really sure. They're not all that useful in anything like text layout, but they're useful for various tricks such as ensuring that images don't increase the line box height any more than necessary. > A testcase: > <span style="vertical-align: top" ><img src="test.png" />in span > </span>text<img src="test.png" /> > > It seems to me that only one browser makes the first image bleed > upwards, which should be the correct way to render the above > according to the rec i belive? Assuming that the image is tall enough, this is the unsolvable case described in [2]. There is no possible layout that does not contradict a requirement of CSS2 or of the current draft of CSS 2.1. Hopefully we can clarify this case in a future draft of CSS 2.1, perhaps with the solution in [2], described in more detail in [1]. -David [1] http://dbaron.org/css/2000/01/dibm [2] http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html -- L. David Baron <URL: http://dbaron.org/ >
From: Paul Grosso (pgrosso@arbortext.com)
Date: 2003-10-08
Archive: http://www.w3.org/mid/4.3.2.7.2.20031008173446.01709bf8@172.27.10.30
In Section 5.8.2 "Default attribute values in DTDs" at http://www.w3.org/Style/Group/css2-src/diffs-rec/selector.html#q11 this LC WD says: Matching takes place on attribute values in the document tree. Default attribute values may be defined in a DTD or elsewhere, but cannot be selected by attribute selectors. First I note this wording is not compliant with RFC 2119, but I assume by "cannot" you mean "MUST not" as opposed to "SHOULD not". I find this very objectionable. This forbids an HTML-tree generating processor from being compliant with SGML and XML. In fact, for most APIs to SGML/XML trees, there is no way to tell whether a given attribute value is set in the instance or in the DTD by defaulting. Finally, this forbids some very useful scenarios where DTD-defaulted attribute values are key to certain processing. Granted, given that many (delivery) presentation systems do not read the DTD, I could agree that: Style sheets SHOULD be designed so that they work even if the default values are not included in the document tree. but I object to saying that it is non-compliant to the CSS spec for any process--especially one such as an authoring tool or other special processor--to base selector action on DTD defaults. Certainly, there are many XML processes that read the DTD when creating the document tree, and the current wording makes these tools non-complaint with CSS2.1. paul
From: staffan.mahlen@comhem.se
Date: 2003-10-09
Archive: http://www.w3.org/mid/3F85B43E.12760.2B3E50@localhost
On 7 Oct 2003 at 12:52, L. David Baron wrote: > > On Tuesday 2003-10-07 21:30 +0200, staffan.mahlen@comhem.se wrote: > > <img style="vertical-align: top" src="test.png" />Text <img > > style="vertical-align: bottom" src="test.png" /> > > What should be the result and why? > > The correct layout is undefined since (using the terminology in [1]) the > tallest loose subtree in the line is not the one established by the root > inline box. I should have thought this through better. Thanks for explaining. I agree that there should be at least a note or something that gives the hint that there are combinations of 'vertical-align' that are undefined. > > > If we switch the last to middle, how does that work > Again using terminology from [1], the tallest loose subtree is now the > one established by the root inline box, so the layout is defined. > > "top > > Align the top of the box with the top of the line box. > > bottom > > Align the bottom of the box with the bottom of the line box." > > > > Why are they not relative to the parent like the other align > > properties? > Because then they'd be equivalent to 'text-top' and 'text-bottom'? Hmm, only if the restriction on non-replaced inline element height to be calculated based only on the text they have or could have i belive. To my mind that and the way margin/border/paddings are handled seem like a problem. > [1] http://dbaron.org/css/2000/01/dibm I actually read this one a few times a while ago and thought i understood it at the time. It is very helpful. This time around i wonder if i am still only half-getting it... > [2] http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html Again, thanks for the very informative answer. /Staffan
From: Jukka K. Korpela (jkorpela@cs.tut.fi)
Date: 2003-10-09
Archive: http://www.w3.org/mid/Pine.GSO.4.58.0310092216090.16941@korppi.cs.tut.fi
On Wed, 8 Oct 2003, Paul Grosso wrote: > Matching takes place on attribute values in the document tree. > Default attribute values may be defined in a DTD or elsewhere, > but cannot be selected by attribute selectors. > > First I note this wording is not compliant with RFC 2119, but I > assume by "cannot" you mean "MUST not" as opposed to "SHOULD not". The wording is somewhat obscure, since "the document tree" is to be taken as a tree-like presentation of the actual markup used, as opposite to the element structure indicated. I guess. > I find this very objectionable. This forbids an HTML-tree generating > processor from being compliant with SGML and XML. In fact, for most > APIs to SGML/XML trees, there is no way to tell whether a given > attribute value is set in the instance or in the DTD by defaulting. But in the WWW world, conformance to SGML has never been much more than lip service. Nothing that the WWW related specifications say about SGML should be taken at face value. It suffices to say that none of the common browsers ever supported HTML as defined as an SGML application, e.g. supporting tag minimization. On the other hand, it is not clear what SGML really means by defaulted attribute values. This topic was once discussed in the newsgroup comp.infosystems.www.authoring.stylesheets, and I really tried to understand the SGML view on attributes. It _seemed_ to me that in the SGML universe, all elements have all attributes (which is rather analogous to the principle that in CSS all elements have all properties), i.e. that this is the general idea, but I was unable to find an explicit statement about it. In the CSS universe, the situation could be clarified simply by making it more explicit what attribute selectors mean. It would surely be meaningless if the selector type [att] were defined in a context where all elements have all attributes, so the _intent_ is relatively clear. But there's still the open question whether attributes defaulted with a DTD-supplied default value are different from attributes defaulted with no explicit default value, i.e. with a default value that depends on the application (browser, that is). This could be avoided by adding a simple statement: All references to attributes in CSS shall be taken as referring to attributes that have been explicitly set using attribute specifications in the document's markup. Of course, some simple explanation might clarify: For example, input[type="text"] matches only those input elements that have an explicit type attribute with the value "text", not those input elements that lack any type type attribute, even though the type attribute has a default value of "text". Such a principle can be regarding as illogical and surprising, and it will surely cause some inconvenience, but the more explicitly it is expressed, the smaller the damage. -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Ian Hickson (ian@hixie.ch)
Date: 2003-10-09
Archive: http://lists.w3.org/Archives/Public/www-style/2003Oct/0029.html
On Wed, 8 Oct 2003, Paul Grosso wrote: > > In Section 5.8.2 "Default attribute values in DTDs" at > http://www.w3.org/Style/Group/css2-src/diffs-rec/selector.html#q11 > this LC WD says: > > Matching takes place on attribute values in the document tree. > Default attribute values may be defined in a DTD or elsewhere, > but cannot be selected by attribute selectors. > > [...] I object to saying that it is non-compliant to the CSS spec for > any process--especially one such as an authoring tool or other special > processor--to base selector action on DTD defaults. Certainly, there > are many XML processes that read the DTD when creating the document tree, > and the current wording makes these tools non-complaint with CSS2.1. When we discussed this, we (the CSS working group) considered that interoperability between all implementations was more important than supporting the use cases you describe in some of the implementations. Interoperability is _the_ primary goal of CSS2.1. As we cannot require all XML processors to be validating parsers, we cannot rely on information within the DTD for selector matching, and in order to have interoperability, we must therefore require that all UAs _ignore_ such information. Otherwise stylesheets could result in radically different (yet equally valid) renderings depending on whether the UA was validating or non-validating. The requirement that the processor be able to tell if the attribute was defaulted or not is already made by DOM, and was therefore not considered to be a new requirement. [1] The allowance that processors not have to read DTDs was made by XML, and is therefore also not new. [2] Finally, XHTML already requires that content be written in such a way that the resulting DOM be equivalent whether or not the document is read via a validating or non-validating parser (namely, the #FIXED attribute on the root element is required to be in the document despite being #FIXED), and thus we felt there was precedent for this decision. [3] All three of the above-referenced specifications are already in REC stage. [1] http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-862529273 [2] http://www.w3.org/TR/REC-xml.html#proc-types [3] http://www.w3.org/TR/xhtml1/#strict -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Jukka K. Korpela (jkorpela@cs.tut.fi)
Date: 2003-10-10
Archive: http://www.w3.org/mid/Pine.GSO.4.58.0310101624150.4119@korppi.cs.tut.fi
On Thu, 9 Oct 2003, Ian Hickson wrote: > On Thu, 9 Oct 2003, Jukka K. Korpela wrote: > > > > This could be avoided by adding a simple statement: All references to > > attributes in CSS shall be taken as referring to attributes that have > > been explicitly set using attribute specifications in the document's > > markup. > > "Default attribute values may be defined in a DTD or elsewhere, but cannot > be selected by attribute selectors." > > That's exactly what that sentence is trying to say. More or less so, I guess. But it doesn't really say it. It's obscure - for example, selectors don't really select attributes, do they? My point is that the formulation needs a clarification, which is best formulated as part of the very _definition_ of the meaning of attribute selectors, rather than a vague statement of what can or cannot be done. -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: fantasai (fantasai@escape.com)
Date: 2003-10-10
Archive: http://www.w3.org/mid/3F875337.6080406@escape.com
Preceding Siblings
------------------
S5.1 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#q1>:
# E + F Matches any F element immediately preceded by an element E.
preceded by a _sibling_ element, you mean; E + F shouldn't match if
E is the parent of F.
Adjacent Elements
-----------------
S5.7<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#adjacent-selectors>:
# In some contexts, adjacent elements generate formatting objects
# whose presentation is handled automatically (e.g., collapsing
# vertical margins between adjacent boxes). The "+" selector
# allows authors to specify additional style to adjacent elements.
This paragraph is confusing and, imo, useless. Take it out.
Attribute Selectors
-------------------
S5.8<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#attribute-selectors>:
# CSS 2.1 allows authors to specify rules that match attributes
# defined in the source document.
Given the way "matches" is defined in section 5.1, this
sentence should be reworded. The selector doesn't match
the attribute, it matches the element *with* the attribute.
Default Attributes
------------------
S5.8.2<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#q11>
# EXAMPLE { /*... default property settings ...*/ }
# Because this selector is less specific than an attribute
# selector, it will only be used for the default case.
This is false. The selector will be used for all cases,
not just the default case. If a declaration from this
rule conflicts with one from a more specific rule, then
it will be overridden--but the declaration still applies.
Class Selectors
---------------
S5.8.3<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#class-html>:
# Working with HTML, authors may use the period (.) notation
# as an alternative to the ~= notation when representing the
# class attribute. Thus, for HTML, div.value and
# div[class~=value] have the same meaning. The attribute
# value must immediately follow the "period" (.). UAs may
# apply selectors using the period (.) notation in XML
# documents if the UA has namespace specific knowledge that
# allows it to determine which attribute is the "class"
# attribute for the respective namespace. One such example
# of namespace specific knowledge is the prose in the
# specification for a particular namespace (e.g. SVG 1.0
# [SVG10] describes the SVG "class" attribute and how a UA
# should interpret it, and similarly MathML 2.0 [MATH20]
# describes the MathML "class" attribute.)
The poor quality of the prose here aside (which I'll have
to address later), I think this paragraph would benefit
from a brief discussion of what a class /is/ conceptually,
not just syntactically.
Also, you need to make clear that an XML namespace may
choose as its class attribute an attribute with a name
other than "class".
# Note. CSS gives so much power to the "class" attribute,
# that authors could conceivably design their own "document
# language" based on elements with almost no associated
# presentation (such as DIV and SPAN in HTML) and assigning
# style information through the "class" attribute. Authors
# should avoid this practice since the structural elements
# of a document language often have recognized and accepted
# meanings and author-defined classes may not.
You tell authors here what not to do with classes. One
reads this warning, but then what? There's no advice on
what *to* do! Tantek's post "A Touch of Class" [1]
explains classes particularly well; adding a few key
points from that would turn this block into a more useful
redirect.
[1] http://tantek.com/log/2002/12.html#L20021216t2238
ID Selectors
------------
S5.9<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#class-html>:
# Document languages may contain attributes that are
# declared to be of type ID. What makes attributes of
# type ID special is that no two such attributes can
# have the same value; whatever the document language,
# an ID attribute can be used to uniquely identify its
# element...
Since CSS could conceivably be used for a non-SGML-based
document language, I suggest defining IDs as "unique
identifiers" first and relating them to type ID later.
Another advantage is that you start the definition with
generic English rather than specific code.
:first-child
------------
S5.11.1<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-child>:
# Note that since anonymous boxes are not part of the
# document tree, they are not counted when calculating
# the first child.
-Boxes- are never part of the document tree. You mean
to say that "non-element nodes" are not counted.
Link Pseudo-Classes
-------------------
S5.11.2<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#link-pseudo-classes>
# For example, in HTML 4.0, the link pseudo-classes apply
# to A elements with an "href" attribute.Thus, the
# following two CSS 2.1 declarations have similar effect:
#
# a:link { color: red }
# :link { color: red }
This example seems a bit pointless. If it's got a point,
you need to point it out. Otherwise, take it out.
# Note. It is possible for stylesheet authors to abuse the
# :link and :visited pseudo-classes to determine which sites
# a user has visited without the user's consent. UAs may
# therefore treat all links as unvisited links, or implement
# other measures to preserve the user's privacy while
# rendering visited and unvisited links differently. See
# [P3P] for more information about handling privacy.
If you want to let UAs treat all links as unvisited, then
put that in the normative prose, not an informative note.
As for privacy concerns over :visited and :link, putting
that kind of a note in here seems like overkill to me.
Dynamic Pseudos
---------------
S5.11.3<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#dynamic-pseudo-classes>:
# Similarly, because A:active is placed after A:hover,
# the active color (lime) will apply when the user both
# activates and hovers over the A element.
will apply -> will take effect
# An element can be both ':visited' and ':active' (or
# ':link' and ':active') and the normal cascading rules
# determine which properties apply.
which _style declarations_ apply
:first-line
-----------
This entire section takes the "fictional tag sequence" idea
a bit too literally. For example,
# the user agent could generate the appropriate start and
# end tags for SPAN when inserting the fictional tag
# sequence for :first-line.
No. You can't make the tags real, because then you wind up
with an obscure box model. Suppose, for example, I specify
span { border: 1px solid}. The border shouldn't indicate a
split in the span element at the end of the first line.
# The :first-line pseudo-element can only be attached to
# a block-level element.
elem { display: block; }
elem:first-line { color: blue; }
elem.special { display: inline; }
say what?
# A UA should act as if the fictional start tag of the
# first-line pseudo-element is just inside the smallest
# enclosing block-level element.
What do you mean, the "smallest enclosing block-level
element"?
If you're trying to say something about nesting (I'm
guessing based on the example), then *say* something
about nesting. E.g.
:first-line pseudo-elements are nested in the
same order as the elements themselves.
~fantasai
From: fantasai (fantasai@escape.com)
Date: 2003-10-11
Archive: http://www.w3.org/mid/3F87E24C.10509@escape.com
Defining "background-attachment: scroll"
----------------------------------------
This part taken mostly from
http://lists.w3.org/Archives/Public/www-style/2003Mar/0005.html
From http://www.w3.org/TR/2003/WD-CSS21-20030915/colors.html :
| If a background image is specified, this property specifies
| whether it is fixed with regard to the viewport ('fixed')
| or scrolls along with the containing block ('scroll').
|
| Note that there is only one viewport per view. If an element
| has a scrolling mechanism (see 'overflow'), a 'fixed'
| background doesn't move with the element, and a 'scroll'
| background doesn't move with the scrolling mechanism.
I think the behavior specified here for 'scroll' is counter-
intuitive. As an author, I would expect the background to scroll
with the element's content just like it does for the <body>.
Indeed this is how several browsers have implemented it. [1]
As a user, I find backgrounds fixed to the content easier to
read, and while having text scroll over an unmoving background
looks cool, it is somewhat distracting. If CSS dictates that
"background-attachment: scroll" no longer scrolls the background
with the text [2], I shall be therefore be somewhat annoyed. (At
the browser manufacturers, most likely.)
I propose that 'scroll' be defined to attach the background
and the content so that they scroll together and that, if
needed, a new keyword 'attached' be defined to attach the
background to the element's box as CSS2.1 currently specifies
for 'scroll'.
The main counter argument seems to be that the behavior of the
background underneath the element's border becomes awkward to
define. [3]
Well, what if the background didn't get painted underneath the
border--what if it was clipped to the padding edge?
Defining the Background Clip Area
---------------------------------
Aside from a single inconsistency, the original CSS2 wording
specifies that the background is clipped to the padding box
and therefore does not extend to the border area. [4]
The CSS2 Errata and, hence, the CSS2.1 draft turn the spec
around, considering the area under the border as part of the
background area.
But the new definition results in buggy-looking rendering
and a less-consistent model:
- Because the positioning box and the clip box are not the
same, an untiled large image "bleeds" messily through the
border. Illustration:
http://lists.w3.org/Archives/Public/www-style/2001Nov/0088.html
(Part C)
- CSS3's background-size stretches the background to the
padding edge, but the background color by default continues
through the border, splitting the *viewer's* perception of
the background into two unmatched layers.
- Specifying the boundaries of backgrounds on border-collapse
tables needs to be special-cased.
- Constraining the background to the padding area would allow
CSS to define "background-attachment: scroll" more intuitively.
Conclusion of Logic:
By locking the proposed clarifications of "background-attachment:
scroll" and the background's boundaries together, we get a
background model that is both more consistent and more intuitive
than the one drafted in CSS2.1.
Whether these changes can be made, however, depends on the state
of current implementations as we don't want to break backward
compatibility in CSS2.1.
Current State of Implementations
--------------------------------
1. As explained in [1] and [2], the current state of implementations
favors defining "background-attachement: scroll" as proposed
above.
2. As explained in [5], the current implementations' background
boundaries are inconsistent with each other and, except for
Mozilla, inconsistent with themselves.
Conclusion of Testing:
There doesn't appear to be any significant backwards-compatibility
problem for constraining the background to the padding box or for
defining "background-attachment: scroll" to scroll the background
with the content.
Summary of Argument
-------------------
- The behavior of "scroll" would be most intuitive if the background
scrolled with the content, as it's called "scroll" and as is how the
setting behaves when specified for the main canvas.
- Text content is easier to read if the background scrolls with the
content instead of remaining fixed to the element's position.
- If CSS3 is to introduce a third value for "background-attachment" to
make it possible to specify either of the interpretations of
"scroll", it can just as easily introduce a new keyword (such as
'attached') for attaching the background to the element position as
for attaching the background to the element's content.
- The main problem with having the background scroll with the content
is figuring out what to do with the background underneath the
borders. This problem can be avoided by keeping the background
within the padding box.
- Keeping the background within the padding box eliminates the
"bleeding" untiled image problem.
- Keeping the background within the padding box prevents the image/
color background boundary dichotomy.
- Keeping the background within the padding box makes it easier to
have the background scroll with the content.
- The current state of implementations does not seem to be preventing
this model from becoming official.
==========================================================================
[1] Testcase:
http://fantasai.tripod.com/www-style/2003/background-attachment.html
With "background-attachment: scroll", these browsers scroll
the background with the content:
Mozilla (& Netscape et al.) *
IE Win
These follow the CSS2.1 draft's wording:
Opera 7.0
MacIE
Safari
* Although Mozilla actually does both at once (See Ian's test case:
http://www.hixie.ch/tests/adhoc/css/background/block/002.html )
transparent background images are rare enough that in almost
all cases, the perception is that it scrolls the background
with the content like IE Win.
[2] In CSS1, 'scroll' means that the background "scrolls along
with the content"; CSS2 changes this to "scrolls along with
the document". A very high percentage of the browser market
share is consistent with CSS1's wording, so the expectations
of both authors and users likely favor scrolling along with
the content.
[3] Ian Hickson wrote:
| The working group discussed this at length.
...
| http://www.hixie.ch/tests/adhoc/css/background/block/001.html
|
| What would you say should happen under the borders?
-- http://lists.w3.org/Archives/Public/www-style/2003Mar/0008.html
[4] fantasai wrote:
| The CSS2 spec, in four other places, refers to the
| behavior specified in 14.2, where 'background' is defined.
| Only in Section 8.5.3 does it extend 'background' to the
| border area.
|
| 14.2 - In defining "background", the spec writes that it
| gets painted in the content and padding areas.
| Borders styles are mentioned in a separate sentence
| dealing with border properties.
|
| 14.2 def 'background-image' - The spec writes that tiling
| only covers content and padding areas.
| 14.2 def 'background-attachment' - The spec writes that a
| a background image is only visible within the
| padding and content areas.
| 8.1 - The spec states that the backgrounds of the padding
| and content areas are specified by the background
| properties, but that the background of the border
| area is specified by the border properties. (This
| can make sense because content that overflows the
| border is rendered on top of it, not underneath it.)
| 17.5.1 - The image depicting a table with background-
| colored, double-bordered cells does not show any of
| the background between the two stripes of border.
|
| This leads me to believe that whoever wrote backgrounds
| into the spec expected them to render in the content and
| padding areas, but not the border area.
-- http://lists.w3.org/Archives/Public/www-style/2001Jul/0189.html
[5] Background boundary browser testing results and comments:
Microsoft Internet Explorer:
They render 0% 0% as upper left corner of the padding edge
and tile/color only the padding box EXCEPT when
a) the element is not a table
and b) the element has both auto width and auto height
in which case they render 0% 0% as the upper left corner of
the *border* box and tile/color the border box.
Opera, Konqueror, and Safari:
They position AND tile the background image within the
padding box, but fill the entire border box with the
background color.
Mozilla:
Previous versions of Mozilla behaved like Opera and Safari.
Recent ones position the background image within the padding
box but tile it into the border area.
Conclusions:
Current implementations are inconsistent. Choosing to constrain
both background color and image tiling to the padding box should
cause no more problems than expanding them to the border box.
========================================================================
~fantasai
From: fantasai (fantasai@escape.com)
Date: 2003-10-11
Archive: http://www.w3.org/mid/3F87E607.9030501@escape.com
S14.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/colors.html#q2>: # The background of the root element becomes the background of the # canvas and covers the entire canvas, anchored at the same point # as it would be if it was painted only for the root element itself. # The root element does not paint this background again. It is unclear what is meant by this. S14.2.1<http://www.w3.org/TR/2003/WD-CSS21-20030915/colors.html#background-properties>: # The tiling and positioning of the background-image on inline elements # is undefined in this specification. A future level of CSS may define # the tiling and positioning of the background-image on inline elements. Must CSS2.1 really make the tiling and positioning of all inline elements undefined or can it get away with leaving backgrounds on *multi-line* inline elements undefined? # The computed value of background-position for the purpose of # inheritance is undefined, since the allowed values on this property # may have different effects in a child element due to differences in # size and position of their respective boxes. I don't see why this is a reason to leave the inherited value undefined. Using the computed value--"for <length> the absolute value, otherwise a percentage"--seems reasonable to me. ~fantasai
From: fantasai (fantasai@escape.com)
Date: 2003-10-11
Archive: http://www.w3.org/mid/3F879634.2070002@escape.com
S5.12.2<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-letter>
Constitution
------------
# Punctuation (i.e, characters defined in Unicode [UNICODE] in the
# "open" (Ps), "close" (Pe), and "other" (Po) punctuation classes),
# that precedes the first letter should be included, as in:
What about punctuation immediately following the first letter?
Imagine the following with a drop-caps effect:
M. Lafayette ést parti de France...
É? NÃn shÅ«o shénme? WÇ’ tÄ«ng bù dÇ’ng. QÄng nÃn...
"A" is the first letter of the alphabet. Remarkably consistent
across scripts, it...
There's also this degenerate case to consider:
"_", the underscore, was used on typewriters...
The first *letter* is 't', but surely it should not be part of the
:first-letter pseudo-element.
And what of numbers? They're not letters, but...
67 million dollars is a lot of money.
Should :first-letter hold the '6' or the 'm'?
Language-Specific Requirements
------------------------------
# Some languages may have specific rules about how to treat certain
# letter combinations. In Dutch, for example, if the letter
# combination "ij" appears at the beginning of a word, both letters
# should be considered within the :first-letter pseudo-element.
The UA requirents wrt such combinations should be, IMO, more clearly
expressed.
S5.12.3<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#before-and-after>
Before and After
----------------
# When the :first-letter and :first-line pseudo-elements are combined
# with :before and :after, they apply to the first letter or line of
# the element including the inserted text.
#
# Example(s):
#
# p.special:before {content: "Special! "}
# p.special:first-letter {color: #ffd800}
#
# This will render the "S" of "Special!" in gold.
/I/ think it should render the first letter of the paragraph itself
in gold. Here's why:
H1:before {content:counter(chapno, upper-roman) ". "}
:first-letter {font-size: larger; color: #ffd800;}
<h1>Planes in Spain</h1>
If this gives me
XII. Planes in Spain
I would want the P in "Plane" to be affected, not the X in "XII".
Not good enough? Try this:
BODY { margin-left: 8.5em; }
P { text-indent: 5%; }
:first-letter { font-size: larger;
color: #ffd800; }
P.note:before { content: "Note:";
margin-left: -8em;
width: 7.5em;
float: left;
color: green; }
DIV.example:before { content: "Example";
display: block;
margin: 0.5em;
margin-left: -2em;
font-weight: bold; }
Is it better that the N in "Note:" be gold or the first letter of the
note itself?
Is it better that the E in "Example" be gold or the first letter of
the example's text?
<http://fantasai.inkedblade.net/style/demos/first-letter/www-style>
If I specifically want to make the N in "Note:" bigger, I should be
able to do this:
P.note:before:first-letter { font-size: 110%; }
/That/ makes sense.
(":first-letter:before", though, does not.)
~fantasai
From: Felix Breuer (felix@fbreuer.de)
Date: 2003-10-11
Archive: http://www.w3.org/mid/20031011130232.GA3710@tapir
Hello!
Looking at both "CSS 2.1" and "CSS 3: the box model" I could not find out
how the following is supposed to be rendered:
Case A:
<div class="block">
<div class="runin">Is this supposed</div>
<div class="inline">to run in?</div>
</div>
Case B:
<div class="block">
<div class="runin">Is this supposed</div>
to run in?
</div>
Case C:
<div class="block>
<div class="runin">Is this supposed</div>
<div class="block">to run in?</div>
</div>
where
block { display: block }
runin { display: run-in }
inline { display: inline }
Intuitively I would say, that in all three cases the text should be
displayed in a single line (if there is enough space). In Case C this is
the behaviour specified in CSS 2.1 and 3:
CSS 3: "If the next element [after a run-in element] [...] has a 'display-model'
of 'block-inside', the current element will be rendered as if it had
display-role 'inline' and was the first child of that block element."
CSS 2.1: "If a block box follows the run-in box, the run-in box becomes the first
inline box of the block box."
However in cases A and B these excerpts do not seem to apply, instead
CSS 3: "Otherwise this element will be rendered as if it had
display-role 'block'."
CSS 2.1: "Otherwise, the run-in box becomes a block box."
which would cause the text to be renderd in two lines.
Thus, A and B are only rendered on one line, if
1) the run-in element is initially taken as a block-level element
2) the following inline element/text is wrapped in an anonymous block
box
3) the following anonymous block box causes the run-in to become the
first child of the anonymous box with display role "inline"
This "algorithm" seems highly confusing to me. In what order are
user-agents supposed to determine the display-roles of run-in elements
and whether or not an inline element needs to be wrapped in an anonymous
block box? Is this specified anywhere? To answer the first question you
need to know the answer to the second and vice versa.
I can understand that a W3 recommendation is not supposed to tell
implementors _how_ to implement a given behaviour. But in this case the
recommended behaviour can only be determined by guessing which algorithm
the authors of the spec had in mind. This makes implementing conforming
user-agents unnecessarily difficult.
Regards,
Felix Breuer
From: Felix Breuer (felix@fbreuer.de)
Date: 2003-10-11
Archive: http://www.w3.org/mid/20031011235501.GA2332@tapir
On 17:12 Sat 11 Oct , fantasai wrote:
>
> Felix Breuer wrote:
> >
> >Looking at both "CSS 2.1" and "CSS 3: the box model" I could not find out
> >how the following is supposed to be rendered:
> >
> ><div class="block">
> > <div class="runin">Is this supposed</div>
> > <div class="inline">to run in?</div>
> ></div>
> ...
>
> Might want to take a look at
> http://lists.w3.org/Archives/Public/www-style/2000May/0004.html
>
> While we're on the topic, though, I'd like to bring up
> http://lists.w3.org/Archives/Public/www-style/2000May/0010.html
> as well.
These two mails basically say that a run-in element followed by an
inline element are rendered as two blocks (on two lines). However,
the CSS3 Box draft refers to "Ian's tests" [1] and there it says
<div class="test">
<span class="h block"> This is a block on its own. </span>
<span class="g run-in"> This text should </span>
<span class="g inline"> run-in to this one. </span>
<!-- ...because the inline is wrapped in an anonymous block box. -->
</div>
Am I right in concluding that the intended sequence of events is
1) The user agent encounters the first element and determines its
display-role. Since this is "block" all "inline" siblings are wrapped
in anonymous block boxes. This wrapping takes place immediately.
1a) The user agent checks whether the second element has to be
wrapped. Since it is a "run-in" element it is not wrapped, even
though it has not been determined whether the "run-in" element
will become a "block" or an "inline" element.
1b) The user agent wraps the third element because this is clearly
inline.
2) The user agent encounters the run-in element, notices that a block
box follows and thus adds the run-in as an inline box to the anonymous
block box.
..
Hm, this algorithm still looks funny to me. Does it reflect the intended
behaviour?
Thanks,
Felix Breuer
From: fantasai (fantasai@escape.com)
Date: 2003-10-11
Archive: http://www.w3.org/mid/3F879150.9020504@escape.com
I propose changing the 'normal' value to 'auto':
| It should also be renamed to 'auto', as 'auto' means "self"--
| which is a connotation you'll want in CSS3. It also means
| "automatic"; the content and behavior associated with the
| element is "automatic" instead of manually specified in the
| style rule. In contrast, 'normal' here means little more
| than 'default', and it implies that any other value is
| "abnormal". ;)
|
| If the WG still feels 'normal' is more appropriate than 'auto',
| I would *really* like to know why. *formally requests a reply*
-- http://lists.w3.org/Archives/Public/www-style/2003Mar/0013.html
~fantasai
From: staffan.mahlen@comhem.se
Date: 2003-10-12
Archive: http://www.w3.org/mid/3F89D7DF.13755.2A8DAB4@localhost
On 12 Oct 2003 at 13:47, Ian Hickson wrote: > On Wed, 1 Oct 2003, staffan.mahlen@comhem.se wrote: > > How do nested and adjacent block formatting contexts interact? > > Depends on how they are formed. Floats, for instance, generate block > formatting contexts, and flow around each other as per section 9.5. > > In general, formatting contexts grow to contain their in-flow floats, but > do not grow to contain out-of-flow content. If this is generally true i think it may be useful to spell that out in the rec (while it may be difficult to describe). If i understand correctly, absolutely positioned block formatting contexts do not affect containing block formatting contexts, while the others do (except for overflow:scroll containing an absolutely positioned element?). > However, for specific rules, > you have to refer to the spec. For example, 'overflow:scroll' generates a > new block formatting context that grows to contain any out-of-flow content > (assuming the 'overflow:scroll' box is the containing block of the > absolutely positioned block, or is a containing block ancestor of the > containing block of the absolutely positioned block. > > Does that answer your question? I think so, at least the nesting bit. I'm not quite sure i got the adjacent part though. Eg: <div style="float: left; width:100px; height: 100px">A float</div> <table> <tr> <td>A cell</td> </tr> </table> I'm not quite sure where in the rec that is defined (and i dont quite see why browsers implement it the way they seem to do). /Staffan
From: Tim Bagot (tsb-w3-style-0007@earth.li)
Date: 2003-10-12
Archive: http://lists.w3.org/Archives/Public/www-style/2003Oct/0050.html
At 2003-10-12T15:03+0200, Maximilian Baumgart wrote:-
> If you want to have this "double-italic", than simply write it in the
> style sheet of your site. For instance:
>
> em em, em q, q q, q em {font-style:normal;}
>
> Where's the problem?
It's not a convention I'm especially fond of, but if you do want it, the
problem with doing it that way is that you can only ever specify it for a
finite (though arbitrarily high) level of nesting, and the number of
selectors required grows exponentially.
Tim Bagot
From: staffan.mahlen@comhem.se
Date: 2003-10-13
Archive: http://www.w3.org/mid/3F8AF0D5.15739.531E32@localhost
On 13 Oct 2003 at 15:03, Ian Hickson wrote: > I believe the spec does say this. Oh perhaps it does. It seems i was trying to figure this out the wrong way around with false assumptions on what the block formatting contexts meant. Since floats are covered, items with non-initial overflow does not need any explanation, table-cells are covered (by UA specific...) i suppose the only issue might be inline-block:s. That is a very minor issue if it isen't covered already by virtue of being shrink-wrapped, eg cell-like. The adjacent bit was a part of my confused idea of what a block formatting context was, and made me think they should always be cleared rather than pseudo-floated. Thanks for filling me in, /Staffan
From: Ian Hickson (ian@hixie.ch)
Date: 2003-10-13
Archive: http://www.w3.org/mid/Pine.LNX.4.58.0310131334280.29626@dhalsim.dreamhost.com
On Sun, 12 Oct 2003, staffan.mahlen@comhem.se wrote: >> >> In general, formatting contexts grow to contain their in-flow floats, but >> do not grow to contain out-of-flow content. > > If this is generally true i think it may be useful to spell that out > in the rec (while it may be difficult to describe). I believe the spec does say this. For example, for floats, in the section defining the height of a float (10.6.6 Floating, non-replaced elements), it says: # In addition, if the element has any floating descendants whose top # margin edge is above the top established above or whose bottom margin # edge is below the bottom, then the height is increased to include those # edges. For absolutely positioned content (10.6.4 Absolutely positioned, non-replaced elements, item 3), it says: # [...] the height is based on the content [...] ...and leaves the exact algorithm up to the UA. For table cells (17.5.3 Table height algorithms), it says: # In CSS 2.1, the height of a cell box is the maximum of the table cell's # 'height' property and the minimum height required by the content (MIN). # A value of 'auto' for 'height' implies a that the value MIN will be used # for layout. ...and leaves the exact algorithm up to the UA. > If i understand correctly, absolutely positioned block formatting > contexts do not affect containing block formatting contexts, while the > others do (except for overflow:scroll containing an absolutely > positioned element?). There is no overall rule. That's why I said "in general". Basically, each way of generating a block formatting context has its own rules for determining its height and its effect on the surrounding flow. The key about block formatting contexts is how they act inwards, not that they act outwards. If they were all the same outwardly, they'd all be the same and there wouldn't be much point in them existing. :-) > <div style="float: left; width:100px; height: 100px">A float</div> > <table> > <tr> > <td>A cell</td> > </tr> > </table> > I'm not quite sure where in the rec that is defined (and i dont quite > see why browsers implement it the way they seem to do). Section 9.5 Floats says: # The margin box of an element in the normal flow that establishes a new # block formatting context (such as a table, or element with 'overflow' # other than 'visible') must not overlap any floats in the same block # formatting context as the element itself. If necessary, implementations # should clear the said element by placing it below any preceding floats, # but may place it adjacent to such floats if there is sufficient space. -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Henri Sivonen (hsivonen@iki.fi)
Date: 2003-10-13
Archive: http://www.w3.org/mid/69421B63-FE02-11D7-8E9F-003065B8CF0E@iki.fi
On Thursday, Oct 9, 2003, at 20:03 Europe/Helsinki, Ian Hickson wrote: > On Wed, 8 Oct 2003, Paul Grosso wrote: >> [...] I object to saying that it is non-compliant to the CSS spec for >> any process--especially one such as an authoring tool or other special >> processor--to base selector action on DTD defaults. Certainly, there >> are many XML processes that read the DTD when creating the document >> tree, >> and the current wording makes these tools non-complaint with CSS2.1. Also I think that requiring different treatment of an attribute depending on whether it was defaulted is a bad idea. In general, I think treating XML differently depending on syntactic details that aren't supposed to have semantic significance is a bad idea. That is, in practical terms, if an application needs to know more than is exposed via the SAX ContentHandler interface (excluding the qName of elements), the design of the application is highly likely flawed in some way. > Interoperability is _the_ primary goal of CSS2.1. As we cannot require > all > XML processors to be validating parsers, we cannot rely on information > within the DTD for selector matching, and in order to have > interoperability, we must therefore require that all UAs _ignore_ such > information. You could state that CSS UAs which are Web browsers should not process external entities when parsing XML. The interoperability problems that stem from external DTDs aren't limited to attribute defaulting. OTOH, things declared in the internal DTD subset aren't interoperability problems to begin with. > The requirement that the processor be able to tell if the attribute was > defaulted or not is already made by DOM, and was therefore not > considered > to be a new requirement. [1] The DOM can expose things that really shouldn't matter to most applications. The DOM can make a difference between CDATA sections and normal text nodes, can expose entity references, can expose comments and can expose the literal text of the internal subset. Still, having selectors match on CDATAness, comment adjacency or doctype would be bad ideas. Besides, isn't static CSS rendering supposed to be implementable without the W3C DOM? > The allowance that processors not have to read DTDs was made by XML, > and > is therefore also not new. [2] Is there anything that prevents the CSS WG from recommending that Web browsers opt not to read the external DTD subset? > Finally, XHTML already requires that content be written in such a way > that > the resulting DOM be equivalent whether or not the document is read > via a > validating or non-validating parser (namely, the #FIXED attribute on > the > root element is required to be in the document despite being #FIXED), > and > thus we felt there was precedent for this decision. [3] If the DOM trees are required to be equivalent in any case, surely then the CSS spec doesn't need to say anything about it. :-) For XHTML family documents whose DTD is based on the Modularization of XHTML, the DOM trees are equivalent only if the xmlns attributes are omitted in the DOM or explicitly specified for every element. The XHTML DTD modules default the xmlns attribute on every element. This means that it is unpractical to make an XHTML 1.1 document standalone (as specified in the XML spec). Infoset augmentation is problematic. I think using Relax NG over DTDs is the right way to go for XHTML 2. > All three of the above-referenced specifications are already in REC > stage. Making requirements *in a rendering spec* about what an XML processor should expose seems to me to be on track to end up in the similar class of requirements you found "pathetic" and "inappropriate" about one of those RECs. See http://lists.w3.org/Archives/Public/www-talk/2001MayJun/0141.html -- Henri Sivonen hsivonen@iki.fi http://www.iki.fi/hsivonen/
From: Roger Larsson (roger.larsson@incrementa.se)
Date: 2003-10-13
Archive: http://www.w3.org/mid/200310131858.36221.roger.larsson@incrementa.se
> > > > Matching takes place on attribute values in the document tree. > > Default attribute values may be defined in a DTD or elsewhere, > > but cannot be selected by attribute selectors. > > > > [...] I object to saying that it is non-compliant to the CSS spec for > > any process--especially one such as an authoring tool or other special > > processor--to base selector action on DTD defaults. Certainly, there > > are many XML processes that read the DTD when creating the document tree, > > and the current wording makes these tools non-complaint with CSS2.1. > > When we discussed this, we (the CSS working group) considered that > interoperability between all implementations was more important than > supporting the use cases you describe in some of the implementations. > > Interoperability is _the_ primary goal of CSS2.1. As we cannot require all > XML processors to be validating parsers, we cannot rely on information > within the DTD for selector matching, and in order to have > interoperability, we must therefore require that all UAs _ignore_ such > information. Otherwise stylesheets could result in radically different > (yet equally valid) renderings depending on whether the UA was validating > or non-validating. > Doesn't that mean that a CSS UA won't be able to correctly present XML that depends on #FIXED and/or default values? Stylesheets could result in radically different renderings depending on if the XML uses #FIXED and/or default values or not. If so, doesn't that either limit the applicability of CSS, or seriously affect XML-authoring? Is the fact that there might be some CSS UA that do not read the DTD, really a good justification to forbid everyone else to do it? There are CSS-properties that not all UAs understand or interpret correctly, but that is surely not a good reason to forbid all other UAs to implement them. If one would like to achieve complete interoperability, doesn't one have to forbid everything except the lowest common denominator among every existing CSS UA? Maybe there is and will be many UAs that do not validate against the DTD but that is not needed anyway, reading the DTD and applying the default values is enough. In my opinion, reading a DTD is a small task compared to implementing the full CSS2.1 specification, and those using an ordinary main stream XML-processor have it for free. I think the amount of UAs that would be affected by a requirement to also read the DTD is small, and it would be a pity if they are allowed to cripple CSS as a tool. // Roger
From: David Woolley (david@djwhome.demon.co.uk)
Date: 2003-10-13
Archive: http://www.w3.org/mid/200310132109.h9DL96B01219@djwhome.demon.co.uk
> XML processors to be validating parsers, we cannot rely on information > within the DTD for selector matching, and in order to have > interoperability, we must therefore require that all UAs _ignore_ such > information. Otherwise stylesheets could result in radically different It seems to me that you are missing a third category of user agent, which is actually the dominant class, namely those with specific application knowledge about the language in use, but which do not read this from a DTD, e.g. the typical HTML web browser. If, for example, one denies the existence of entities defined for HTML (not the specific issue here) you violate the "least astonishment" principle.
From: Henri Sivonen (hsivonen@iki.fi)
Date: 2003-10-14
Archive: http://www.w3.org/mid/78A033BB-FE02-11D7-8E9F-003065B8CF0E@iki.fi
On Tuesday, Oct 14, 2003, at 00:09 Europe/Helsinki, David Woolley wrote: >> XML processors to be validating parsers, we cannot rely on information >> within the DTD for selector matching, and in order to have >> interoperability, we must therefore require that all UAs _ignore_ such >> information. Otherwise stylesheets could result in radically different > > It seems to me that you are missing a third category of user agent, > which > is actually the dominant class, namely those with specific application > knowledge about the language in use, but which do not read this from > a DTD, e.g. the typical HTML web browser. Typical HTML browsers use a tag soup processor--not an XML processor. > If, for example, one denies the existence of entities defined for HTML > (not the specific issue here) you violate the "least astonishment" > principle. Either the full set of HTML entities should have been included as predefined in the XML spec or dropped out of the XHTML DTDs. The astonishment isn't caused by browsers but follows from the specs. OTOH, if you wished to avoid the astonishment by having the full set of HTML entities defined without reading the DTD, the parser wouldn't be a conforming XML processor and it would be inappropriate to use such a parser to parse an XML content type. -- Henri Sivonen hsivonen@iki.fi http://www.iki.fi/hsivonen/
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-15
Archive: http://www.w3.org/mid/3F8DF771.AFB20E72@i18nguy.com
David,
ok, now I see what you mean about the connection between \A and white-space.
I was thinking I might want the output to be data (perhap in a file) that was
going to be sent to a specific model printer.
I have no way of emitting U+000A, if that is what the device needs for an
escape sequence or line control.
It is perhaps not a large problem, if the device has its own escape mechanism
for specifying characters.
As for the text, I agree, but I would remove the parentheses as well since this
is actually the place defining that \A stands for newline.
To include a newline in a string, use the escape "\A" (hexadecimal A is the
line feed character in Unicode, but represents the generic notion of "newline"
in CSS).
to:
To include a newline in a string, use an escape representing the line feed
character in Unicode (U+000A), such as "\A"
or "\00000a". This character represents the generic notion of "newline" in CSS.
Just a suggestion and I recognize you probably can't use the Unicode notation
without changing a number of other character references. For consistency I
guess you can replace 'U+000A' with 'character 10 in Unicode or "A" in
hexadecimal'
tex
"L. David Baron" wrote:
>
> On Wednesday 2003-10-15 19:47 -0400, Tex Texin wrote:
> > However, the example referenced in "content", has to do with generating text
> > and the output format generally does not have those grammatical rules, and in
> > fact may be destined for a media which there is a significant difference
> > between lf, nl, etc. (For example to a specific printer.)
>
> I don't see how the destination medium is relevant. The content
> generated by the 'content' property will be processed as described in
> section 16.6 [1], just like any other content.
>
> > However, the questions about whether \a, \0A and \0a are equivalent to \A
> > should also be addressed.
>
> I think they're definitely equivalent. If anything suggests that they
> aren't, it should be fixed. I guess that means we should change, in
> section 4.3.7 [2], the text
>
> use the escape "\A"
>
> to be:
>
> use an escape such as "\A"
>
> -David
>
> [1] http://www.w3.org/TR/2003/WD-CSS21-20030915/text.html#white-space-prop
> [2] http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#strings
>
> --
> L. David Baron <URL: http://dbaron.org/ >
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: L. David Baron (dbaron@dbaron.org)
Date: 2003-10-15
Archive: http://www.w3.org/mid/20031015223936.GB5773@darby.dbaron.org
On Wednesday 2003-10-15 17:39 -0400, Tex Texin wrote: > http://www.w3.org/TR/CSS21/syndata.html : > > The range should be [0-9a-fA-F], since characters g-zG-Z are clearly > beyond the hexadecimal number. Agreed. > 2) Section 4.4 on CSS document representation > Mention should be made of the Unicode BOM and its relationship to the encoding > of the file. Porting the additional text in [2] back to CSS 2.1 could be a start, although it might be worth adding some additional text beyond that. (For example, a BOM could indicate that a stylesheet is UTF-16, as having priority immediately lower than @charset.) > 5) The section 4.3.7 on strings introduces \A for newline and points to an > example, so I assume there isn't a section describing other backslash codes > (e.g. \t etc.). However, the section doesn't define what the user should do if > they actually want a linefeed. > > Is \0A (not \A) supposed to generate a linefeed or a newline? In other words, > is that string "\A" a special string, or is the character code U+000A mapped to > linefeed in css? The parenthetical remark seems to indicate that CSS redefines > the Unicode character. > > (Which seems like a very odd and dangerous thing to do.) XML normalizes CR, LF, and CRLF to LF [1], so it seems reasonable to treat LF as the new line character within the CSS processing model. It only matters when 'white-space' is 'pre', though. Do you have a better alternative in mind? -David [1] http://www.w3.org/TR/2000/REC-xml-20001006#sec-line-ends [2] http://www.w3.org/TR/2003/WD-css3-syntax-20030813/#css-style -- L. David Baron <URL: http://dbaron.org/ >
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-15
Archive: http://www.w3.org/mid/3F8DDC83.8FE77A0B@i18nguy.com
Thanks for the quick reply.
"L. David Baron" wrote:
I removed agreed point.
> > 2) Section 4.4 on CSS document representation
> > Mention should be made of the Unicode BOM and its relationship to the encoding
> > of the file.
>
> Porting the additional text in [2] back to CSS 2.1 could be a start,
> although it might be worth adding some additional text beyond that.
> (For example, a BOM could indicate that a stylesheet is UTF-16, as
> having priority immediately lower than @charset.)
The text would be a good start, although as the questions in the css3 doc
indicate, it needs more.
I am not sure about the BOM precedence. The W3C allows documents to be
transcoded, which invalidates the @charset rule and presumes that http will
provide the new encoding information. I don't know if these transcoders add
BOMs or not.
However, if the transcoded file is then saved, it could be useful to have the
BOM provided by a transcoder override the @charset rule, since files on disk
don't have the benefit of http charset.
I am not really sure if this is a realistic scenario. I am sure others will
comment.
> > 5) The section 4.3.7 on strings introduces \A for newline and points to an
> > example, so I assume there isn't a section describing other backslash codes
> > (e.g. \t etc.). However, the section doesn't define what the user should do if
> > they actually want a linefeed.
> >
> > Is \0A (not \A) supposed to generate a linefeed or a newline? In other words,
> > is that string "\A" a special string, or is the character code U+000A mapped to
> > linefeed in css? The parenthetical remark seems to indicate that CSS redefines
> > the Unicode character.
> >
> > (Which seems like a very odd and dangerous thing to do.)
>
> XML normalizes CR, LF, and CRLF to LF [1], so it seems reasonable to
> treat LF as the new line character within the CSS processing model. It
> only matters when 'white-space' is 'pre', though.
>
> Do you have a better alternative in mind?
In the context of parsing text that conforms to a particular grammar, it is a
perfectly reasonable thing to do.
However, the example referenced in "content", has to do with generating text
and the output format generally does not have those grammatical rules, and in
fact may be destined for a media which there is a significant difference
between lf, nl, etc. (For example to a specific printer.)
I was just looking for a way to specify U+000A, if \A is given this behavior.
We just need an alternative to express U+000A, or a way to escape the \A.
However, the questions about whether \a, \0A and \0a are equivalent to \A
should also be addressed.
Unless the WG feels there are a lot of existing stylesheets using \0A to mean
newline, I could see treating \A and \a as special values meaning newline and
\0A...\00000A, and the lower case versions, meaning U+000A.
tex
>
> -David
>
> [1] http://www.w3.org/TR/2000/REC-xml-20001006#sec-line-ends
> [2] http://www.w3.org/TR/2003/WD-css3-syntax-20030813/#css-style
>
> --
> L. David Baron <URL: http://dbaron.org/ >
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: L. David Baron (dbaron@dbaron.org)
Date: 2003-10-15
Archive: http://www.w3.org/mid/20031016005340.GA6839@darby.dbaron.org
On Wednesday 2003-10-15 19:47 -0400, Tex Texin wrote: > However, the example referenced in "content", has to do with generating text > and the output format generally does not have those grammatical rules, and in > fact may be destined for a media which there is a significant difference > between lf, nl, etc. (For example to a specific printer.) I don't see how the destination medium is relevant. The content generated by the 'content' property will be processed as described in section 16.6 [1], just like any other content. > However, the questions about whether \a, \0A and \0a are equivalent to \A > should also be addressed. I think they're definitely equivalent. If anything suggests that they aren't, it should be fixed. I guess that means we should change, in section 4.3.7 [2], the text use the escape "\A" to be: use an escape such as "\A" -David [1] http://www.w3.org/TR/2003/WD-CSS21-20030915/text.html#white-space-prop [2] http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#strings -- L. David Baron <URL: http://dbaron.org/ >
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-15
Archive: http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
Sorry, this is after last call's deadline, but I have a couple comments on
section 4,
http://www.w3.org/TR/CSS21/syndata.html :
1) In section 4.1.3, in the third type of escape it says that if a character in
the range [0-9a-zA-Z] follows a hexadecimal number, the end of the number needs
to be made clear.
The range should be [0-9a-fA-F], since characters g-zG-Z are clearly beyond the
hexadecimal number.
2) Section 4.4 on CSS document representation
Mention should be made of the Unicode BOM and its relationship to the encoding
of the file.
Is BOM allowed?
The @charset rule is required to be the first character of the file. For some
people, it is confusing whether the BOM is considered a character. (To me it is
clear that it is not.)
Where does BOM fit in the precedence hierarchy?
What if the UTF-8 BOM exists, but the encoding is declared by @charset rule as
something else?
Is this an error, or is it considered that the encoding simply changes after
the @charset rule?
3) More generally, I find the character numbering a little confusing. It is in
fact self-consistent, but it is not obvious to the reader without some checking
and if you don't recognize the values.
If you take into account:
-In 4.1.1 Tokenization it is mentioned that Octal codes refer to ISO 10646.
(This is specific to Lex expressions but that is not immediately obvious. I
realize saying octal refers to 10646 doesn't mean that the reverse is true,
10646 codes will be in octal. But it doesn't mean it isn't true either.)
-The character codes at the end of 4.1.1 are decimal. Although one code (space)
is identified as a Unicode value.
-All of the escapes are of course hex.
Then, when you read in section 4.1.3 that ISO 10646 characters 161 and higher
are allowed in identifiers, it is not immediately obvious if 161 is octal,
decimal or hex.
It would perhaps be more clear to use the Unicode notation for character codes:
U+hhhh, as the hex notation is more common now and the U+ is distinctive and
indicative of the notation. The hex values are more recognizable as well, for
characters like ideographic space, etc.
and fit in better with the escape notation.
4) I am surprised that the on section URIs doesn't mention IRIs.
5) The section 4.3.7 on strings introduces \A for newline and points to an
example, so I assume there isn't a section describing other backslash codes
(e.g. \t etc.). However, the section doesn't define what the user should do if
they actually want a linefeed.
Is \0A (not \A) supposed to generate a linefeed or a newline? In other words,
is that string "\A" a special string, or is the character code U+000A mapped to
linefeed in css? The parenthetical remark seems to indicate that CSS redefines
the Unicode character.
(Which seems like a very odd and dangerous thing to do.)
Also I assume that \a and \A are equivalent. True?
tex
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-16
Archive: http://www.w3.org/mid/3F8E6343.710045EE@i18nguy.com
A couple of comments on text-transform-
The first is a pet peeve of mine, which I hope can be addressed.
I find in a number of browsers, that if text-transform is used to change case,
and a user highlights and copies the text to the clipboard (on Windows anyway),
the text that is placed in the clipboard is the original text (ie without case
changes) not the properly cased text displayed in the highlighted region.
I think this behavior is very contrary to user expectations.
It would be good if the CSS spec would specify cut/copy clipboard behavior with
respect to functions that change text.
Should the original text or the resulting text be placed on the clipboard?
Second, the spec says:
"...consider the value of 'text-transform' to be 'none' for characters that are
not from the Latin-1 repertoire and for elements in languages for which the
transformation is different from that specified by the case-conversion tables
of ISO 10646 ([ISO10646]). "
a) I suspect you mean EITHER/OR not AND.
ie the value can be none if characters are EITHER not from Latin-1 OR for
elements...
For example the letter i uses different conversion values in Turkey, and I
assume that even though it is a latin-1 letter, you intended for the conversion
to not be required.
I guess if the AND is intentional, you are saying that it is better to do no
case conversion than do the wrong conversion.
However, this seems silly, since then implementors need to have a list of
characters that have different conversions for certain languages and insure
that no conversion is performed. At the point you are detecting these
characters and language contexts, you may as well implement the correct
conversion.
b) From an international perspective, I don't see why you mention latin-1 at
all. Why should latin-2 users for example not have the benefit of
text-transform? Why not simply require support for the 10646 case conversion
table, since Unicode character support is more generally required elsewhere?
Given everything else needed to implement CSS, the Unicode case conversion
table seem to be a very small burden to implementers.
3) The reference to 2070 should be upgraded to rfc 3066.
Also, what should occur if the empty language tag is specified for the language
in XML? Use the default conversion or perform no conversion? What if the tag is
"UND"?
tex
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-16
Archive: http://www.w3.org/mid/3F8E49FF.A8ABAA98@i18nguy.com
Section 5.11.4 on :lang still references RFC 1766.
Although HTML technically refers to 1766, XML has been upgraded to RFC 3066 for
its support of 3 letter tags and also prescribes the empty tag to allow the
removal of language info. And most browsers I believe do support rfc 3066 for
html anyway.
CSS should therefore address rfc 3066 and the empty tag as well.
Does ':lang()' match elements that have language set to the empty tag?
It might be thought to match all languages, since in the absence of simple
selectors, * is presumed, so it is conceivable that absence of a tag might be
equivalent to all. It might also be deemed to be an error to have no tag inside
the parens.
So the spec should address the issue.
For the purposes of matching, I wonder if it makes sense to reference the RFCs
at all. Isn't it really string matching based on strings formatted with hyphen
separators? Does any software verify that the language tag contains
appropriately registered codes or uses ISO codes? Should it be an error, or
perhaps the rule ignored, if a CSS document specifies :lang(k9) since k9 is
not an offical language code or a properly formatted private code.
tex
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: Martin Duerst (duerst@w3.org)
Date: 2003-10-16
Archive: http://www.w3.org/mid/4.2.0.58.J.20031016210049.05b36ad0@localhost
At 17:39 03/10/15 -0400, Tex Texin wrote: >Sorry, this is after last call's deadline, but I have a couple comments on >section 4, >http://www.w3.org/TR/CSS21/syndata.html : >3) More generally, I find the character numbering a little confusing. It is in >fact self-consistent, but it is not obvious to the reader without some >checking >and if you don't recognize the values. This seems to be not only a little confusing, but baroque and out of date. I'm sure there are versions or equivalents to lex these days that can use something different than octal. And decimal is also way out of fashion these days in anything connected with character encoding, and Unciode in particular. I sincerely hope that this can be fixed. The readers will be grateful for a long time to come. Regards, Martin. >If you take into account: > >-In 4.1.1 Tokenization it is mentioned that Octal codes refer to ISO 10646. >(This is specific to Lex expressions but that is not immediately obvious. I >realize saying octal refers to 10646 doesn't mean that the reverse is true, >10646 codes will be in octal. But it doesn't mean it isn't true either.) > >-The character codes at the end of 4.1.1 are decimal. Although one code >(space) >is identified as a Unicode value. > >-All of the escapes are of course hex. > >Then, when you read in section 4.1.3 that ISO 10646 characters 161 and higher >are allowed in identifiers, it is not immediately obvious if 161 is octal, >decimal or hex. > >It would perhaps be more clear to use the Unicode notation for character >codes: >U+hhhh, as the hex notation is more common now and the U+ is distinctive and >indicative of the notation. The hex values are more recognizable as well, for >characters like ideographic space, etc. >and fit in better with the escape notation.
From: Bert Bos (bert@w3.org)
Date: 2003-10-16
Archive: http://www.w3.org/mid/16270.39061.194849.106208@lanalana.inria.fr
Tex Texin writes:
>
> Section 5.11.4 on :lang still references RFC 1766.
>
> Although HTML technically refers to 1766, XML has been upgraded to RFC 3066 for
> its support of 3 letter tags and also prescribes the empty tag to allow the
> removal of language info. And most browsers I believe do support rfc 3066 for
> html anyway.
>
> CSS should therefore address rfc 3066 and the empty tag as well.
>
> Does ':lang()' match elements that have language set to the empty tag?
>
> It might be thought to match all languages, since in the absence of simple
> selectors, * is presumed, so it is conceivable that absence of a tag might be
> equivalent to all. It might also be deemed to be an error to have no tag inside
> the parens.
> So the spec should address the issue.
Good point.
I think it is not useful to make ':lang()' match *all* languages,
since you can already do that by omitting the ':lang()' altogether.
Making it an error is a possibility.
But making it match elements with no language seems the most useful,
especially since it parallels RFC 3066.
>
> For the purposes of matching, I wonder if it makes sense to reference the RFCs
> at all. Isn't it really string matching based on strings formatted with hyphen
> separators? Does any software verify that the language tag contains
> appropriately registered codes or uses ISO codes? Should it be an error, or
> perhaps the rule ignored, if a CSS document specifies :lang(k9) since k9 is
> not an offical language code or a properly formatted private code.
I like that suggestion: it removes a dependency.
The definition of the "|=" operator is already generic. It only
requires a UA to split a string value at every "-" and doesn't require
the string to be a valid language. The ':lang()' refers to that
definition and could be made generic as well, e.g.:
Current text in 5.11.4:
The pseudo-class ':lang(C)' matches if the element is in language
C. Here C is a language code as specified in HTML 4.0 [HTML40] and
RFC 1766 [RFC1766]. It is matched the same way as for the '|='
operator.
Proposed:
The pseudo-class ':lang(C)' matches if the element is in language
C. CSS doesn't define what are valid language names and the string
C doesn't have to be a valid language name in the source document.
It is matched the same way as for the '|=' operator.
And in 5.8.1, in the informative reference to RFC 1766, "1766" is
replaced by "3066."
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-16
Archive: http://www.w3.org/mid/3F8F32D8.1EA24826@i18nguy.com
I wasn't proposing to change the source content. When text is highlighted and
copied from a screen, I think users expect to have the visualized text on the
screen, not the source. The visualized text is the content as far as they are
concerned.
Don't change the source content, just put the generated text on the clipboard.
You might want the source, but as the document author you are the only one that
knows what to expect. The rest of us will be surprised...
Most people expect what they see to be copied.
So if the screen has all headings lowercased, they expect it to be lowercase in
the clipboard, regardless of how the source was written.
I do like the suggestion that the clipboard could have the html & css source on
the clipboard as one of the formats.
However, my main point is that UA should be consistent (I think) and so the
spec should prescribe clipboard behavior, so they all do the same thing.
If we don't have agreement on that, then UA's can do whatever they want and
there is no point in debating which approach is right.
tex
Richard Ishida wrote:
>
> > I find in a number of browsers, that if text-transform is
> > used to change case, and a user highlights and copies the
> > text to the clipboard (on Windows anyway), the text that is
> > placed in the clipboard is the original text (ie without case
> > changes) not the properly cased text displayed in the
> > highlighted region.
> >
> > I think this behavior is very contrary to user expectations.
>
> Absolutely not contrary to my expectations when I use this ! I'm using
> the CSS for *presentation-related* adaptation. I use text-transform to
> change the visual appearance - not the stored text. This enables me to
> achieve different capitalization styling for exactly the same HTML text
> by applying different style sheets. For example, one of my styles
> lowercases all the text in headings, but I *don't* want it to change the
> content while doing so.
>
> > It would be good if the CSS spec would specify cut/copy
> > clipboard behavior with respect to functions that change
> > text. Should the original text or the resulting text be
> > placed on the clipboard?
>
> RI
>
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: Martin Duerst (duerst@w3.org)
Date: 2003-10-16
Archive: http://www.w3.org/mid/4.2.0.58.J.20031016205044.05b71008@localhost
At 21:42 03/10/15 -0400, Tex Texin wrote: >David, > >ok, now I see what you mean about the connection between \A and white-space. > >I was thinking I might want the output to be data (perhap in a file) that was >going to be sent to a specific model printer. >I have no way of emitting U+000A, if that is what the device needs for an >escape sequence or line control. CSS is not XSLT. XSLT is a file-to-file conversion. CSS just defines how things are rendered; making sure that the right codes are sent to a printer is a job for the CSS implementation and/or the printer driver. >Just a suggestion and I recognize you probably can't use the Unicode notation >without changing a number of other character references. For consistency I >guess you can replace 'U+000A' with 'character 10 in Unicode or "A" in >hexadecimal' A propos 'character 10 in Unicode': Using octal or decimal numbers for Unicode characters is a very bad idea. If CSS does that in any place, this urgently has to be fixed. Regards, Martin.
From: David Woolley (david@djwhome.demon.co.uk)
Date: 2003-10-16
Archive: http://www.w3.org/mid/200310160609.h9G699J02898@djwhome.demon.co.uk
> However, the questions about whether \a, \0A and \0a are equivalent to \A > should also be addressed. Are they actually equivalent to newline or are they really equivalent to line break. HTML is modelled on previous markup languages in which .br or \break only cause vertical motion if there is a partially constructed line present. Most, if not all GUIs mistakely think that it corresponds to the word processor hard return function (typically control-return on the keyboard), but CSS2 (maybe this is clarified) in CSS2.1) specification seems to say that it should produce the effect of HTML <br>, so that you can specify the layout effect of <br> in CSS. One could, I suppose, argue that the large number of abuses of br to simulate p mean that carriage return plus vertical index is the only pragmatic interpration of br these days. (Strictly, excess br elements, like empty p elements, should have no effect.)
From: Richard Ishida (ishida@w3.org)
Date: 2003-10-16
Archive: http://www.w3.org/mid/00a701c39432$f36ba6a0$c401c941@w3c40upc3ma3j2
> I find in a number of browsers, that if text-transform is > used to change case, and a user highlights and copies the > text to the clipboard (on Windows anyway), the text that is > placed in the clipboard is the original text (ie without case > changes) not the properly cased text displayed in the > highlighted region. > > I think this behavior is very contrary to user expectations. Absolutely not contrary to my expectations when I use this ! I'm using the CSS for *presentation-related* adaptation. I use text-transform to change the visual appearance - not the stored text. This enables me to achieve different capitalization styling for exactly the same HTML text by applying different style sheets. For example, one of my styles lowercases all the text in headings, but I *don't* want it to change the content while doing so. > It would be good if the CSS spec would specify cut/copy > clipboard behavior with respect to functions that change > text. Should the original text or the resulting text be > placed on the clipboard? RI
From: David Woolley (david@djwhome.demon.co.uk)
Date: 2003-10-16
Archive: http://www.w3.org/mid/200310162122.h9GLMG703275@djwhome.demon.co.uk
> I find in a number of browsers, that if text-transform is used to change case, It doesn't change the case, only how it is displayed. > and a user highlights and copies the text to the clipboard (on Windows anyway), > the text that is placed in the clipboard is the original text (ie without case > changes) not the properly cased text displayed in the highlighted region. I don't think that this should be within the scope of CSS. I would expect, though, that what goes onto the clipboard should depend on the clipboard format used. Many tools create multiple clip board versions. I would expect the plain text version (the one that notepad will use) to be the text as sent, minimally formatted. If there is a suitable rich text format that can support the forced uppercase attribute, I would expect that version to have the original case, plus the attribute and for rich text type tools to convert it to their own attribute representation, retaining the original case. Of course, such a rich text aware tool, that didn't have a corresponding attribute, could chose to destroy the capitalisation information in preference to destroying the information from the attribute. Forcing the case in CSS is not an alternative to using caps lock when keying the text in. An alternative style sheet may not force the case, and the text should be written so that it is capitalised in a way that is correct if represented with no transformation. Actually, it would seem to me fairly reasonable that an HTML browser should create one of its clip board formats as (an operating system specific) format that is very similar to HTML plus CSS, to preserve as much as possible of the information from the original document. That might be seen as undesirable by some content publishers as it might reduce the technical knowledge needed to plagiarize. On the other hand, various arguments about whether inline styles are really needed seem to be based on the assumption that such copy as HTML operations will be provided.
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-16
Archive: http://www.w3.org/mid/3F8F64B9.2776AC68@i18nguy.com
Yes, I understand the difference between CSS and XSLT.
Perhaps I work with too many environments where printing is not thru drivers.
Ignore the file comment, in a lot of these environments the data is first saved
in a file, but it could be sent directly to a printer.
In any event I don't feel strongly about the \A, if no one else sees any risk
in there being a requirement to actually have an LF instead.
As for the decimal numbers, they are used in 4.1.1. I see that U+hhhh syntax is
used elsewhere in CSS, so the references to decimal codes should be changed in
sec 4 to use the same syntax.
The octal reference is to the macro definitions
escape {unicode}|\\[ -~\200-\4177777]
It would be nice if this could be changed to hex, but it is under the covers
for css implementers and is probably not critical.
tex
Martin Duerst wrote:
>
> At 21:42 03/10/15 -0400, Tex Texin wrote:
>
> >David,
> >
> >ok, now I see what you mean about the connection between \A and white-space.
> >
> >I was thinking I might want the output to be data (perhap in a file) that was
> >going to be sent to a specific model printer.
> >I have no way of emitting U+000A, if that is what the device needs for an
> >escape sequence or line control.
>
> CSS is not XSLT. XSLT is a file-to-file conversion. CSS just
> defines how things are rendered; making sure that the right
> codes are sent to a printer is a job for the CSS implementation
> and/or the printer driver.
>
> >Just a suggestion and I recognize you probably can't use the Unicode notation
> >without changing a number of other character references. For consistency I
> >guess you can replace 'U+000A' with 'character 10 in Unicode or "A" in
> >hexadecimal'
>
> A propos 'character 10 in Unicode': Using octal or decimal numbers
> for Unicode characters is a very bad idea. If CSS does that in any
> place, this urgently has to be fixed.
>
> Regards, Martin.
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: Martin Duerst (duerst@w3.org)
Date: 2003-10-16
Archive: http://www.w3.org/mid/4.2.0.58.J.20031016203541.07448160@localhost
Hello Tex, Some great work, thanks. A few comments below. At 05:22 03/10/16 -0400, Tex Texin wrote: >A couple of comments on text-transform- > >The first is a pet peeve of mine, which I hope can be addressed. > >I find in a number of browsers, that if text-transform is used to change case, >and a user highlights and copies the text to the clipboard (on Windows >anyway), >the text that is placed in the clipboard is the original text (ie without case >changes) not the properly cased text displayed in the highlighted region. > >I think this behavior is very contrary to user expectations. >It would be good if the CSS spec would specify cut/copy clipboard behavior >with >respect to functions that change text. >Should the original text or the resulting text be placed on the clipboard? I agree with Richard on this one in what the spec should say (at least as long as copying means downgrading to plain text), even though I agree with Tex re. the expectations of some users. Richard in his example is an author, not the end user (reader), and thus knows more and has different expectations. >Second, the spec says: > >"...consider the value of 'text-transform' to be 'none' for characters >that are >not from the Latin-1 repertoire and for elements in languages for which the >transformation is different from that specified by the case-conversion tables >of ISO 10646 ([ISO10646]). " > > >a) I suspect you mean EITHER/OR not AND. I suspect it indeed intended to say AND. When CSS2 was created, Unicode was much less prevalent than now, and many people were afraid to require anything outside Latin-1. This restriction is outdated and should be changed. >For example the letter i uses different conversion values in Turkey, and I >assume that even though it is a latin-1 letter, you intended for the >conversion >to not be required. >However, this seems silly, since then implementors need to have a list of >characters that have different conversions for certain languages and insure >that no conversion is performed. At the point you are detecting these >characters and language contexts, you may as well implement the correct >conversion. Fully agree. Why require a very specific exception for a halfway job? >b) From an international perspective, I don't see why you mention latin-1 at >all. Why should latin-2 users for example not have the benefit of >text-transform? Why not simply require support for the 10646 case conversion >table, since Unicode character support is more generally required elsewhere? >Given everything else needed to implement CSS, the Unicode case conversion >table seem to be a very small burden to implementers. Yes, I agree this is the right thing to do. Keeping the latin-1 restriction would be completely outdated. >3) The reference to 2070 should be upgraded to rfc 3066. >Also, what should occur if the empty language tag is specified for the >language >in XML? Use the default conversion or perform no conversion? What if the >tag is >"UND"? I don't think we need to mention 'UND'. For missing/empty language tags, the default conversion is fine. Regards, Martin.
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-17
Archive: http://www.w3.org/mid/3F8FEAC3.B864436C@i18nguy.com
Not to my mind. We can change terms if that will be less confusing.
Perhaps the source text vs. the transformed text? Or generated text?
For all of the situations I can think of where an application throws text to a
screen, the source is always irrelevant, and the clipboard receives the text
represented on the screen, and stored appropriately in a storage format.
If CSS changes case, or generates content before or after some portions of the
source, I would expect the clipboard to receive the transformed and generated
content. Not the source text ripped from the markup.
To the extent clipboards support multiple formats and encodings of the same
data, I have no objection (and in fact would like it) if the markup was stored,
in addition to the text as I described it.
In the case of bidi, I would expect the logical version of the rendered text to
be stored on the clipboard. But I'll have to go do some testing to confirm what
usually happens on bidi systems. maybe someone else can confirm what happens
when you copy bidi text to the clpboard.
tex
Chris Lilley wrote:
>
> On Friday, October 17, 2003, 2:07:52 AM, Tex wrote:
>
> TT> I wasn't proposing to change the source content. When text is highlighted and
> TT> copied from a screen, I think users expect to have the visualized text on the
> TT> screen, not the source. The visualized text is the content as far as they are
> TT> concerned.
>
> Does that mean, to continue the logical vs visual concept, that bidi
> text should also go on the clipboard in visual order?
>
> --
> Chris mailto:chris@w3.org
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: Chris Lilley (chris@w3.org)
Date: 2003-10-17
Archive: http://www.w3.org/mid/62726204.20031017143909@w3.org
On Friday, October 17, 2003, 2:07:52 AM, Tex wrote: TT> I wasn't proposing to change the source content. When text is highlighted and TT> copied from a screen, I think users expect to have the visualized text on the TT> screen, not the source. The visualized text is the content as far as they are TT> concerned. Does that mean, to continue the logical vs visual concept, that bidi text should also go on the clipboard in visual order? -- Chris mailto:chris@w3.org
From: Charles McCathieNevile (charles@w3.org)
Date: 2003-10-17
Archive: http://www.w3.org/mid/Pine.LNX.4.55.0310170930350.10760@homer.w3.org
On Fri, 17 Oct 2003, Tex Texin wrote: >In the case of bidi, I would expect the logical version of the rendered text to >be stored on the clipboard. But I'll have to go do some testing to confirm what >usually happens on bidi systems. maybe someone else can confirm what happens >when you copy bidi text to the clpboard. I don't have a clipboard inspection, but in OS X when you copy bi-di text it collects the text in logical order, and it pastes neatly, so I suspect they include the bi-di information in the way it copies. test text for copying if you really need it: http://eikeon.com/foaf/?mbox=mailto%3Acharles%40w3.org
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-18
Archive: http://www.w3.org/mid/3F90EEA2.D954C4FB@i18nguy.com
Just a minor typo-
In both descriptions of the border properties "value:, the color is listed as
border-top-color instead of border-color.
fyi
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: Kevin W. (null@ozforces.com.au)
Date: 2003-10-18
Archive: http://www.w3.org/mid/oprw9kt7boou6nf2@smtp.ozforces.com.au
> However, doesn't the same issue hold for width and style, in that each
> of those values can only be a single value?
Actually, it doesn't. If you look closely at the Value definition:
Value: [ <border-width> || <border-style> || <'border-top-color'> ] |
inherit
border-width and border-style do not have quotes. border-top-color does.
This means that <'border-top-color'> is referring to the actual property
'border-top-color' (<color> | transparent | inherit), while <border-width>
is referring to the value type <border-width> (thin | medium | thick |
<length>), and not the property 'border-width' (<border-width>{1,4} |
inherit). See CSS2.1:1.4.2 for an explanation of the syntax definitions.
So <border-width>, <border-style> and <'border-top-color'> can all only be
a single value.
However, <'border-width'>, <'border-style'> and <'border-top'> can be
multiple values.
The syntax definitions are technically correct, though perhaps confusing.
It just turned out this way because the value of border-top-color was
simple enough to define in one go, without having to define a new value
type.
> 2) Since {1,4} is used in places to indicate that up to 4 choices are
> available, {1} might be used to indicate a single choice.
{1, 1} is assumed when it's omitted. See the CSS2.1:1.4.2 for an
explanation of the syntax definitions.
--
Kevin W :-)
Opera/CSS/webdev blog: http://trats.ozforces.com.au/
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Elliotte Rusty Harold (elharo@metalab.unc.edu)
Date: 2003-10-18
Archive: http://www.w3.org/mid/p06002002bbb70a2ea318@%5B192.168.254.4%5D
I hope this is already dealt with in some section of the CSS 2.1 spec
that I haven't read yet, but if not it's a significant issue.
Section 4.1.3 states:
In CSS 2.1, identifiers (including element names, classes, and IDs
in selectors) can contain only the characters [A-Za-z0-9] and ISO
10646 characters 161 and higher, plus the hyphen (-) and the
underscore (_); they cannot start with a hyphen or a digit. They can
also contain escaped characters and any ISO 10646 character as a
numeric code (see next item). For instance, the identifier "B&W?" may
be written as "B\&W\?" or "B\26 W\3F".
This rules out the colon character which is widely used in XML names.
It is not possible given this to write a simple rule such as
pre:name { font-weight: bold}
You could escape the colon; e.g.:
pre\3Aname { font-weight: bold}
I can't find any other workaround in the spec. Ideally we'd want the
ability to match on namespace URI and local name rather than
qualified name. However, that will probably have to wait for CSS3.
In the meantime, it's quite hard to match against colonized names,
which are frequently used in XML. It's certainly not intuitive. Is
there any way the colon can be allowed into CSS identifiers?
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Processing XML with Java (Addison-Wesley, 2002)
http://www.cafeconleche.org/books/xmljava
http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2003-10-18
Archive: http://www.w3.org/mid/3F90F357.90204@mit.edu
Tex Texin wrote: > In both descriptions of the border properties "value:, the color is listed as > border-top-color instead of border-color. Actually, this is correct, as far as I can tell. 'border-top-color' allows a single color value, while 'border-color' allows anywhere from 1 to 4 color values. The former is valid in the "border" and "border-top/right/bottom/left" shorthands, while the latter is not. The choice of 'top' was arbitrary, though -- it would be just as easy to use any of the other sides or to define a new value set (<single-border-color>?) and use that in all the relevant spots. -Boris
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-18
Archive: http://www.w3.org/mid/3F91919C.B11E5F0A@i18nguy.com
If that is intentional, then there should be a footnote or an explanation.
The name single-border-color would be more meaningful.
However, doesn't the same issue hold for width and style, in that each of those
values can only be a single value?
Two alternatives would be:
1) use border-color and border-colors as appropriate.
2) Since {1,4} is used in places to indicate that up to 4 choices are
available, {1} might be used to indicate a single choice.
But all in all, I think border-color would do and is clear.
tex
Boris Zbarsky wrote:
>
> Tex Texin wrote:
>
> > In both descriptions of the border properties "value:, the color is listed as
> > border-top-color instead of border-color.
>
> Actually, this is correct, as far as I can tell. 'border-top-color'
> allows a single color value, while 'border-color' allows anywhere from 1
> to 4 color values. The former is valid in the "border" and
> "border-top/right/bottom/left" shorthands, while the latter is not.
>
> The choice of 'top' was arbitrary, though -- it would be just as easy to
> use any of the other sides or to define a new value set
> (<single-border-color>?) and use that in all the relevant spots.
>
> -Boris
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: Ian Hickson (ian@hixie.ch)
Date: 2003-10-18
Archive: http://lists.w3.org/Archives/Public/www-style/2003Oct/0138.html
On Sat, 18 Oct 2003, Elliotte Rusty Harold wrote:
>
> This rules out the colon character which is widely used in XML names.
> It is not possible given this to write a simple rule such as
>
> pre:name { font-weight: bold}
In non-namespace-aware browsers, you would do:
pre\:name { font-weight: bold; }
However, this is very poor semantically, as it gives special meaning to
the namespace prefix.
Instead you should use CSS3 Selectors, that are supported by basically all
the namespace-aware XML+CSS browsers:
@namespace foo url(http://example.net/pre);
foo|name { font-weight: bold; }
See: http://www.w3.org/TR/css3-selectors/#typenmsp
Note that the ':' character in CSS has special meaning. The following:
pre:name { font-weight: bold; }
...would mean "pre elements that match the pseudo-class :name should be
bold".
--
Ian Hickson )\._.,--....,'``. fL
U+1047E /, _.. \ _\ ;`._ ,.
http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Robert Koberg (rob@koberg.com)
Date: 2003-10-18
Archive: http://www.w3.org/mid/200310181600.h9IG0Qb16613@server1.livestoryboard.com
Hi ERH,
It is good to see you here :)
We use something like the following to get wysiwyg in our browser-based xml
editor:
c\:article {}
c\:title {}
c\:section {}
We have only done this with IE, since it is the only one that has
contentEditable (Oh.., if it could be a W3 standard...). Don't know how it
would work in other browsers or even if it is spec-compliant... but it
works...
Best,
-Rob
> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
> Of Elliotte Rusty Harold
> Sent: Saturday, October 18, 2003 8:25 AM
> To: www-style@w3.org
>
>
> I hope this is already dealt with in some section of the CSS 2.1 spec
> that I haven't read yet, but if not it's a significant issue.
>
> Section 4.1.3 states:
>
> In CSS 2.1, identifiers (including element names, classes, and IDs
> in selectors) can contain only the characters [A-Za-z0-9] and ISO
> 10646 characters 161 and higher, plus the hyphen (-) and the
> underscore (_); they cannot start with a hyphen or a digit. They can
> also contain escaped characters and any ISO 10646 character as a
> numeric code (see next item). For instance, the identifier "B&W?" may
> be written as "B\&W\?" or "B\26 W\3F".
>
> This rules out the colon character which is widely used in XML names.
> It is not possible given this to write a simple rule such as
>
> pre:name { font-weight: bold}
>
>
> You could escape the colon; e.g.:
>
> pre\3Aname { font-weight: bold}
>
> I can't find any other workaround in the spec. Ideally we'd want the
> ability to match on namespace URI and local name rather than
> qualified name. However, that will probably have to wait for CSS3.
> In the meantime, it's quite hard to match against colonized names,
> which are frequently used in XML. It's certainly not intuitive. Is
> there any way the colon can be allowed into CSS identifiers?
>
> --
>
> Elliotte Rusty Harold
> elharo@metalab.unc.edu
> Processing XML with Java (Addison-Wesley, 2002)
> http://www.cafeconleche.org/books/xmljava
> http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-19
Archive: http://www.w3.org/mid/3F9221BA.B938248A@i18nguy.com
The Long description illustrating relationship between page box and sheet
http://www.w3.org/TR/CSS21/images/longdesc/page-info-desc.html
has a link "return to image" which is incorrect. Should return to the section
on page margins 13.2.1, but instead goes back to section 12.
tex
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-19
Archive: http://www.w3.org/mid/3F93547A.1F7C7C1C@i18nguy.com
Many of the references need updating-
Unicode refers to version 2, should refer to version 4. The comment on bidi in
the corrigenda can be removed.
ISO 10646 should also refer to latest version, parts.
The associated roadmap links also should reflect their new location, as
everson's site has moved.
The CHARSETS IANA registry should refer to the IANA web site.
Reference to RFC 3066 should be added.
Reference to IRI should also be added.
tex
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: Henri Sivonen (hsivonen@iki.fi)
Date: 2003-10-19
Archive: http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
Links to non-normative versions
I suggest providing the diff between CSS 2 and CSS 2.1 with the final
REC and linking to it.
3.1 Definitions
"Element" is defined using a normative reference to SGML. The SGML
standard is not freely available on the Web. Considering it that the
SGML specification is not available for linking and reading on the Web,
I suggest removing the normative reference to SGML and defining
"element" by reference to XML instead.
The definition for "ignore" says there are three meanings. However, it
only list meetings introduced by "First" and "Second".
4.3.2 Lengths
I suggest calling "absolute" units "physical" instead, because people
tend to consider pixels absolute in the context of computer graphics.
5.8.2 Default attribute values in DTDs
The requirement "Default attribute values may be defined in a DTD or
elsewhere, but cannot be selected by attribute selectors." moves from
the realm of rendering to defining what information a XML processor
should expose. Specified attributes and defaulted attributes are
normally considered equivalent as far as the reporting from an XML
processor to an application is concerned. The CSS 2.1 Draft says
building the document tree is beyond the scope of the spec. I think the
CSS 2.1 spec should not require the XML processor to report whether an
attribute was defaulted.
I suggest modifying the passage:
"Default attribute values may be defined in a DTD or elsewhere, but
cannot be selected by attribute selectors. Style sheets should be
designed so that they work even if the default values are not included
in the document tree."
to this
"Default attribute values may be defined in a DTD or elsewhere.
However, non-validating XML processors are not required to process the
external DTD subset, so some user agents do not process attribute
defaults defined in the external DTD subset. Therefore, style sheets
should be designed so that they work both when attributes are defaulted
and when they are not. For interoperability and performance, it is
recommended that Web browsers not process the external DTD subset."
5.9 ID selectors
Unlike class selectors, the id selectors are defined to depend on the
IDness defined in the DTD. For performance reasons, Web browser can
reasonably be expected not to process the external DTD subset.
Therefore, id selectors when used with XHTML would fail in most if not
all Web browsers. I suggest allowing the UA to have hard-coded
knowledge about IDness based on the namespace--just like the UA is
expected to have hard-coded knowledge about what constitutes class.
8.6 The box model for inline elements in bidi context
No definition is given for the term "bidi context".
9.10 Text direction: the 'direction' and 'unicode-bidi' properties
"This seemingly one-sided requirement reflects the fact that, although
not every Hebrew or Arabic document contains mixed-directionality text,
such documents are much more likely to contain left-to-right text
(e.g., numbers, text from other languages) than are documents written
in left-to-right languages."
Probably what is meant is that dominantly RTL documents are more likely
to contain LTR parts than dominantly LTR documents are to contain RTL
parts.
10.1 Definition of "containing block"
The example uses a HTML 4.0 Transitional doctype without a SYSTEM id.
The implementation practice (and CSS 2.1 is about implementation
practice) is not to treat such documents as specified in this section.
It would probably be clearer to use an HTML 4.01 Strict doctype with a
SYSTEM id.
12.3.1 Specifying quotes with the 'quotes' property
"Note. While the quotation marks specified by 'quotes' in the previous
examples are conveniently located on computer keyboards, high quality
typesetting would require different ISO 10646 characters."
I think it would be better to use the high quality alternatives in the
examples.
13 Paged media
"The computed value of box margins at the top or bottom of the page
area is zero."
Is there a reason why same rule doesn't apply to left and right margins
that touch the edges of the page area?
14.3 Gamma correction
" Mac using QuickDraw
apply gamma 1.45 [ICC32] "
I think assuming a particular gamma based on platform is harmful. The
display gamma is configurable on the Mac. When the user agent and
doesn't really know the display gamma, I think it would be better not
to try to "correct" it. Applying "corrections" based on guesses has
been harmful in connection to the PNG format.
See http://iki.fi/hsivonen/png-gamma.html
"(ColorSync-savvy applications may simply pass the sRGB ICC profile to
ColorSync to perform correct color correction)"
The ICC rendering intent is not specified. If a PNG image where is
marked to be in the sRGB color space, which rendering intent should be
specified in order to match CSS colors in a User Agent that does color
matching based on ICC profiles?
15.2 Font matching algorithm
I think the specification is too detailed here. When the page isn't
displayed with the font the author primarily wanted, do this specifics
of the font matching really matter? For example, on Mac OS X ATSUI
already implements a font matching algorithm which could be considered
good enough. Having to implement another matching algorithm on the
application level is a performance problem. Consideration
implementation difficulty, performance and the user experience, I think
passing the list of font alternatives to the system Unicode imaging
service and letting the system apply its fallback algorithm would be
quite sufficient when the system offers font list-based fallback
functionality. Also, considering user experience, allowing (but not
requiring) the user agent to make decisions based on the content of the
entire page is likely to be better than doing per character font
selection.
--
Henri Sivonen
hsivonen@iki.fi
http://www.iki.fi/hsivonen/
From: Henri Sivonen (hsivonen@iki.fi)
Date: 2003-10-20
Archive: http://www.w3.org/mid/C088942F-031D-11D8-B18E-003065B8CF0E@iki.fi
On Monday, Oct 20, 2003, at 09:02 Europe/Helsinki, Tex Texin wrote: > With respect to minority scripts, no - the fact that you can read it > does not > mean automatically that your computer system comes with support for it. If a person can read a minority script and has a system that could display the script, provided that the proper Unicode code points are used and a suitable font is installed, I think it is perfectly reasonable to expect the person to install such a font and choose a browser that can use the services provided by the system. If the infrastructure isn't there, providing a dynamically downloadable font that is properly encoded from the Unicode point of view isn't going to help. Then there's the practice of transferring Latin gibberish and applying a font that is a Latin font from the system's point of view but contains glyphs for another script. I think CSS 2.1 should not accommodate fontifying Latin gibberish to look like text in a minority script in browsers that happen to support such a trick. That approach may appear to work (for some value of "work") in some cases but causes problems with search engines and usually with browsers other than the one the author of the page was using. -- Henri Sivonen hsivonen@iki.fi http://www.iki.fi/hsivonen/
From: David Woolley (david@djwhome.demon.co.uk)
Date: 2003-10-20
Archive: http://www.w3.org/mid/200310200620.h9K6KTl00612@djwhome.demon.co.uk
> I suggest calling "absolute" units "physical" instead, because people > tend to consider pixels absolute in the context of computer graphics. Note that the Web Content Accessibility Guidelines refer to absolute units (specifically: to avoid them) and in that context pixels are regarded as absolute. Also, when one leaves online displays, pixels are treated as absolute units (historically equal to points, but maybe these days more like 72/96th of a point). > and when they are not. For interoperability and performance, it is > recommended that Web browsers not process the external DTD subset." That will break the rendering of the vast majority of current web pages, including some commercially important features, like copyright symbols, because it will deny the use the full range of symbolic entities. As I've said before the vast majority of tools that call themselves web browsers have built in knowledge of HTML DTDs and some even have make an attempt to obey them properly. Pure XML browsers are a techie's tool. Your wording seems to be permitting the processing of internal susbsets; I thought that non-validating parsers were not required to handle any of the DTD at all.
From: Chris Lilley (chris@w3.org)
Date: 2003-10-20
Archive: http://www.w3.org/mid/1535852265.20031020165150@w3.org
On Monday, October 20, 2003, 7:46:09 AM, Kevin wrote: >> I am sure there are good reasons for removing @font-face [2] >> from CSS 2.1 font capabilities. [1]. KW> Probably only because there were no implementations of it at all KW> (AFAIK), Glad you added the AFAIK. KW> and it was deemed too much work for not enough gain. Leaving it in the KW> spec wouldn't have really encouraged UAs to support it. Perhaps it would, perhaps it would not, but taking it our clearly discourages them. KW> It's still in CSS3 though. Big whoop - from Rec to working draft in five years. Thats progress. >> 1) Do I understand correctly that in losing @font-face there is no >> longer a way to specify the url for fonts Yes. KW> Well we've never had an implementation of it. Who is "we"? You missed out the "AFAIK". Given that there are multiple implementations, a bit more research would be a good idea. KW> If a UA wants to support KW> it, they still can, as it's still in the CSS3 spec. >> I have a concern that this impacts users of minority languages more >> than others. KW> I imagine if you want/need to read in a minority script, you would KW> already have the required font(s). If you are a majority user of that language and as long as you are content with always seeing everything in the same font with no stylistic variation. -- Chris mailto:chris@w3.org
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-20
Archive: http://www.w3.org/mid/3F94178C.4C4E50DE@i18nguy.com
If a browser supports Unicode, then all that may be needed to display the
script is the font.
There seems to be an assumption that displaying minority scripts must require a
concerted effort and a specialized system.
It doesn't need to be the case. Certainly some scripts are complex to display.
Others are in the minority not because they are technologically difficult but
because there are not many speakers.
What about the idea of keeping the simpler parts of @font-face, and only
deprecating the more complex or the pieces least likely to be adopted?
tex
Henri Sivonen wrote:
>
> On Monday, Oct 20, 2003, at 09:02 Europe/Helsinki, Tex Texin wrote:
>
> > With respect to minority scripts, no - the fact that you can read it
> > does not
> > mean automatically that your computer system comes with support for it.
>
> If a person can read a minority script and has a system that could
> display the script, provided that the proper Unicode code points are
> used and a suitable font is installed, I think it is perfectly
> reasonable to expect the person to install such a font and choose a
> browser that can use the services provided by the system.
>
> If the infrastructure isn't there, providing a dynamically downloadable
> font that is properly encoded from the Unicode point of view isn't
> going to help.
>
> Then there's the practice of transferring Latin gibberish and applying
> a font that is a Latin font from the system's point of view but
> contains glyphs for another script. I think CSS 2.1 should not
> accommodate fontifying Latin gibberish to look like text in a minority
> script in browsers that happen to support such a trick. That approach
> may appear to work (for some value of "work") in some cases but causes
> problems with search engines and usually with browsers other than the
> one the author of the page was using.
>
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://www.iki.fi/hsivonen/
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: Kevin W. (null@ozforces.com.au)
Date: 2003-10-20
Archive: http://www.w3.org/mid/oprxbua7msou6nf2@smtp.ozforces.com.au
> I am sure there are good reasons for removing @font-face [2] > from CSS 2.1 font capabilities. [1]. Probably only because there were no implementations of it at all (AFAIK), and it was deemed too much work for not enough gain. Leaving it in the spec wouldn't have really encouraged UAs to support it. It's still in CSS3 though. > 1) Do I understand correctly that in losing @font-face there is no > longer a way to specify the url for fonts Well we've never had an implementation of it. If a UA wants to support it, they still can, as it's still in the CSS3 spec. > I have a concern that this impacts users of minority languages more than > others. I imagine if you want/need to read in a minority script, you would already have the required font(s). -- Kevin W :-) Opera/CSS/webdev blog: http://trats.ozforces.com.au/ Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-20
Archive: http://www.w3.org/mid/3F937A78.81E3CDAC@i18nguy.com
If it is going to remain in CSS3, I don't see the point in removing it here. If
anything it is confusing to the industry.
With respect to minority scripts, no - the fact that you can read it does not
mean automatically that your computer system comes with support for it. Often,
these languages are not well-supported, and the publishers of sites using such
languages will make resources available or point to them, so their audience can
use their site.
tex
"Kevin W." wrote:
>
> > I am sure there are good reasons for removing @font-face [2]
> > from CSS 2.1 font capabilities. [1].
>
> Probably only because there were no implementations of it at all (AFAIK),
> and it was deemed too much work for not enough gain. Leaving it in the
> spec wouldn't have really encouraged UAs to support it. It's still in
> CSS3 though.
>
> > 1) Do I understand correctly that in losing @font-face there is no
> > longer a way to specify the url for fonts
>
> Well we've never had an implementation of it. If a UA wants to support
> it, they still can, as it's still in the CSS3 spec.
>
> > I have a concern that this impacts users of minority languages more than
> > others.
>
> I imagine if you want/need to read in a minority script, you would already
> have the required font(s).
>
> --
> Kevin W :-)
> Opera/CSS/webdev blog: http://trats.ozforces.com.au/
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: Chris Lilley (chris@w3.org)
Date: 2003-10-20
Archive: http://www.w3.org/mid/1514084062.20031020162222@w3.org
On Monday, October 20, 2003, 8:31:09 AM, David wrote: >> I am sure there are good reasons for removing @font-face [2] >> from CSS 2.1 font capabilities. [1]. DW> I think that is because it fails the "two interoperable DW> implementations" rule. No, it doesn't. Your statement is factually incorrect. However, I guess its for the CSS WG to explain why they removed this feature. DW> IE and Netscape didn't share a common font format. Of course, there are only two implementations of CSS in the world .... and yes, I suspect that "HTML+CSS browsers we are familiar with" was the reason it was dropped. Which is a poor reason, unless CSS 2.1 starts saying explicitly that it is aimed at HTML+CSS only and not, say, XML+CSS. The font format is irrelevant, incidentally, since Netscape 4.x, which did support a form of font downloading, did not implement CSS @font-face at all. DW> (Note the DW> problem with creating a font format is not describing the font, but DW> enforcing intellectual property rules. Microsoft's implementation DW> locked the font to a particular URL.) >> I have a concern that this impacts users of minority languages more than >> others. Yes, it does. Furthermore, it impacts mobile web users more than others because the 'everyone has fonts by these names' assumption falls down flat there. DW> I don't think there is much awareness of the feature even in such DW> communities. Again, you would need to demonstrate that. DW> The only example I've seen was a Symbol font hack DW> (misrepresenting ISO 8859/1 characters as glyphs for something else) DW> for Telugu. I suggest you look harder if you have seen only a single example. DW> (That was on an explicit search for font-embedding - DW> something that produced few hits at the time.) None of the Western DW> academic sites for Chinese use them, even though people are quite likely DW> not to have the fonts. Since when is Chinese a minority language? Last I looked it was the world's number one language. -- Chris mailto:chris@w3.org
From: fantasai (fantasai@escape.com)
Date: 2003-10-20
Archive: http://www.w3.org/mid/3F9432F6.9080408@escape.com
S7.2.1 Media groups
http://www.w3.org/TR/2003/WD-CSS21-20030915/media.html#media-groups
# This section is informative, not normative.
^^^^^^^^^^^^^^^^^^^^^^^^^^
# Each CSS property definition specifies the media types for which the
# property must be implemented by a conforming user agent.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
????
~fantasai
From: fantasai (fantasai@escape.com)
Date: 2003-10-20
Archive: http://www.w3.org/mid/3F9408C5.2040507@escape.com
S6.1.1: Specified values
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#specified-value
# User agents must first assign a specified value to a property...
^
to _each_ property
# Since it has no parent, the root of the document tree... if necessary.
Take this paragraph out; this case is already handled by the
rules above it.
S6.1.2: Computed values
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#computed-value
# For absolute values, no computation is needed to find the computed value.
Is the computed value of "1cm" and "10mm" the same or different?
Because you need to convert in order to make them the same, and
converting units involves computation...
# However, some properties may define the computed value of a property
# for an element to depend on whether the property applies to that element.
This sentence serves no purpose here and therefore is just confusing.
Take it out.
S6.2: Inheritance
# When inheritance occurs, elements inherit computed values. The
# computed value from the parent element becomes both the specified
# value and the computed value on the child.
...
# Each property may also have a specified value of 'inherit', which
# means that, for a given element, the property takes the same
# computed value as the property for the element's parent.
There's a dichotomy in how the "specified value" for inherited values
works, depending on whether it's explicit or implied. It would be best
if the initial behavior of 'color' and "color: inherit" meant exactly
the same thing. And this way the meaning of "color: inherit" on the
root element would follow from the inheritance logic without having to
be handled as another exception.
# If the user agent does not have the 12pt font available...
Change 120% to 130% and make it 13pt font. Because the vast majority
of fonts out there do have 12pt versions--13pt is not a common size
and is therefore more likely not to exist.
6.3 The @import rule
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#at-import
Move this section to either before Specified, Computed and Actual Values
or after The Cascade, because it breaks up the conceptual flow between
these two sections.
6.4 The Cascade
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#cascade
# Note that the default style sheet may change if system settings are
# modified by the user (e.g., system colors). However, due to limitations
# in a user agent's internal implementation, it may be impossible to
# change the values in the default style sheet.
This note seems rather useless. If there's no good justification for
putting it in, then take it out.
# Rules specified in a given style sheet override rules of the same
# weight imported from other style sheets.
Even if the imported rules have higher specificity?
I think you mean to say that rules in an imported style sheet are
considered to be before the rules in the importing stylesheet.
6.4.2 !important rules
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#important-rules
# the keywords "!" and "important" follow the declaration
Since when is "!" a keyword?
# The first rule in the user's style sheet in the following example...
I think the example would be more illustrative if the second rules
in the author and user style sheets were switched.
S6.4.3: Calculating a selector's specificity
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#specificity
# Concatenating the four numbers a-b-c-d (in a number system with
# a large base) gives the specificity.
Use of dashes here doesn't match use of commas in the examples.
# Note: The specificity is based only on the form of the selector.
# In particular, a selector of the form "[id=p33]" is counted as an
# attribute selector (a=0, b=0, c=1, d=0), even if the id attribute
# is defined as an "ID" in the source document's DTD.
This text should be normative, not informative, and therefore should
not be marked as a note.
Also, move it up to before "Some examples", right after "Contcatenating
the four numbers a-b-c-d (in a number system with a large base) gives
the specificity".
S6.4.4: Precedence of non-CSS presentational hints
# For XHTML and other languages written in XML, no attribute should
# be considered presentational. The styling of elements and
# non-presentational attributes should be handled in the user agent
# stylesheet.
First off, the non-presentational attributes aren't being styled.
The elements to which they belong are being styled based on these
attributes.
Secondly, the 'spacing' attribute of <orderedlist> in DocBook
<http://www.docbook.org/tdg/en/html/orderedlist.html>
is clearly presentational. Trying to deny this is silly. What you
/want/ to do is to restrict the special handling of presentational
hints to HTML.
Like this:
# The UA may choose to honor presentational attributes in the source
# document.
> The UA may choose to honor presentational attributes in an HTML
> source document.
# For XHTML and other languages written in XML, no attribute should
# be considered presentational. The styling of elements and
# non-presentational attributes should be handled in the user agent
# stylesheet.
> For other languages, all document language-based styling should be
> handled in the user agent style sheet.
(SGML needs to be handled somewhere, so one can't say HTML and XML
without leaving room for the general case.)
# The following user stylesheet would override the font weight of
# 'b' elements in all documents, and the color of 'font' elements
# with color attributes...
I personally think an example with <center> and <div align="center">
would be more interesting... =]
~fantasai
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-20
Archive: http://www.w3.org/mid/3F936BA4.123A233C@i18nguy.com
I am sure there are good reasons for removing @font-face [2]
from CSS 2.1 font capabilities. [1].
1) Do I understand correctly that in losing @font-face there is no longer a way
to specify the url for fonts, to make them available automatically if their
retrieval is needed? (formerly @font-face src:url)
I have a concern that this impacts users of minority languages more than
others.
Of course there are other solutions, but the idea that a UA coming to a
document written in a minority script could automatically retrieve the font and
display the document was a nice one.
2) Specifying the Unicode-range for a font to optimize its utilization seemed
like a good idea as well.
In fact, I rather liked the idea that by specifying a range I might preclude a
font from being used for certain characters. I think some fonts are good at one
script and provide other scripts out of necessity but are not that well done.
It would be nice to specify using a font for some characters and require other
fonts for other ranges.
I guess that is a minor optimization and we can forgo it.
I will discuss the removal of the @font-face src:url by the i18n WG.
At the same time, I wonder if it is worth considering scaling @font-face back
rather than removing it altogether, and keeping a few of the better parts?
Perhaps leaving more of the descriptive capability and leaving more of the
matching details up to the UA. (I am just guessing at the reasons for removing
@font-face.)
tex
[1] http://www.w3.org/TR/CSS21/fonts.html
[2] http://www.w3.org/TR/CSS2/fonts.html#font-descriptions
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: Henri Sivonen (hsivonen@iki.fi)
Date: 2003-10-20
Archive: http://www.w3.org/mid/338C56E6-0323-11D8-B18E-003065B8CF0E@iki.fi
On Monday, Oct 20, 2003, at 09:20 Europe/Helsinki, David Woolley wrote: >> and when they are not. For interoperability and performance, it is >> recommended that Web browsers not process the external DTD subset." > > That will break the rendering of the vast majority of current web > pages, > including some commercially important features, like copyright symbols, > because it will deny the use the full range of symbolic entities. I was referring to XML DTDs. Not reading them does not affect the majority of the current Web pages, because the majority is using text/html. The copyright symbol (or any Unicode character for that matter) can be represented without entities. > As I've said before the vast majority of tools that call themselves > web browsers have built in knowledge of HTML DTDs and some even > have make an attempt to obey them properly. Real-world text/html browsers are tag soup processors, so the issues related to real XML DTD processing are of no concern to text/html browsers. > Your wording seems to be permitting the processing of internal > susbsets; Yes. Perhaps it would be better to recommend that Web browsers not process the DTD at all. However, since Mozilla processes the internal subset, there may be a couple of actual use cases out there where that facility is actually used. (IIRC, you had to use the internal subset to declare IDness to the DOM until the DOM IDness was decoupled from DTD IDness. Compare with the definition of IDness in the CSS 2.1 Draft, BTW.) Anyway, those use cases are already incompatible with, for example, Safari which does not process the DTD at all. > I thought that non-validating parsers were not required to handle > any of the DTD at all. They are required to check the internal subset for well-formedness. [1] served as application/xhtml+xml -- Henri Sivonen hsivonen@iki.fi http://www.iki.fi/hsivonen/
From: fantasai (fantasai@escape.com)
Date: 2003-10-21
Archive: http://www.w3.org/mid/3F94ED7C.8070206@escape.com
S8.2 Examples of margins, padding, and borders
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#mpb-examples
# The content width for each LI box is calculated top-down; the
# containing block for each LI box is established by the UL element.
The relationship between these two sentences is not clear. What
does top-down calculation have to do with the UL establishing a
containing block for each LI?
# The right padding of the LI boxes has been set to zero width
# (the 'padding' property). The effect is apparent in the second
# illustration. ^^^^^^^^^^^^^^^^^
No it's not.
S8.3 Margin properties
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#margin-properties
# If the containing block's width depends on this element, then
# the resulting layout is undefined in CSS 2.1.
Might want to give an example of when this happens.
# margin-top, margin-bottom
# Applies to: all elements but inline, non-replaced elements and
# internal table elements
Any reason why it doesn't need to apply to inline, non-replaced
elements? Borders and padding do; they just don't have an effect
on line-height calculation. Since that seems to be the rationale
for excluding it, I'd just combine the definitions for all margins
and leave the no-effect part to the inline model explanation.
S8.3.1 Collapsing margins
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#collapsing-margins
The number of times "clearance" is referred to without reasonable
context or previous definition is just maddening. Call it "float
clearance" or something, at least.
(I've been reading straight through, so continuity problems are
more evident.)
# Vertical margins between a floated box and any other box do not
# collapse (not even between a float and its in-flow children).
Not even between two boxes both floating left? Things would look
nicer imo if these margins would collapse.
S8.5 Border properties
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#border-properties
# Note. Notably for HTML, user agents may render borders for certain
# elements (e.g., buttons, menus, etc.) differently than for "ordinary"
# elements.
Are you sure you want this to be informative?
Also, I suggest adding "user interface" between 'certain' and 'elements'.
S8.5.3
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#border-style-properties
# none
# No border.
I'd put
> No border; the border width is zero.
S8.6 The box model for inline elements in bidi context
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#q11
Beautiful! I would make one change, however:
# the left-most generated box of the first line box in which the
# element appears has a left margin, left border and left padding
^
Change "a left margin" to "the left margin", and likewise for the
other three analogous instances.
~fantasai
From: fantasai (fantasai@escape.com)
Date: 2003-10-21
Archive: http://www.w3.org/mid/3F94ECB2.3080503@escape.com
S9.2.1 Block-level elements and block boxes: Anonymous block boxes
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#anonymous-block-level
# The properties of anonymous boxes are inherited from the enclosing
# non-anonymous box (in the example: the one for DIV).
There's no DIV in the example. (It would make sense for the example
a few paragraphs up, but that's not in range of this sentence.)
# Properties set on elements that are turned into anonymous block boxes
# still apply to the content of the element. For example, if a border
# had been set on the BODY element in the above example, the border
# would be drawn around C1 and C2.
Would the border be drawn as a block border around C1 and another around
C2, or would the border be drawn as an inline border around C1 and another
around C2?
Would the border split where the block occurs? I.e. if it's a block border,
would the bottom border not exist for C1/if it's an inline border, would
the last border not exist for C1?
If it's a block border, then what happens with:
<p>There's an <em>interesting <span class="block">formatting</span>
effect</em> in this paragraph.</p>
em { border: solid }
.block { display: block }
?
S9.2.2 Inline-level elements and inline boxes: Anonymous inline boxes
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#anonymous
# The <p> generates a block box, with several inline boxes inside it...
# ...they don't have an associated inline-level element.
No mention of the conditions for creating an anonymous inline.
S9.2.3: Run-in boxes
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#run-in
# If a block box (that does not float and is not absolutely positioned)
# follows the run-in box, the run-in box becomes the first inline box
# of the block box.
I don't think the intention is to have last-child run-ins combine with
their parents' next-siblings, so change that to "a sibling block box".
Also, see http://lists.w3.org/Archives/Public/www-style/2000May/0010.html
S9.2.4 The 'display' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#display-prop
# and the element itself is formatted as a replaced element on the line.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
change to
as an inline replaced element.
S9.3.1 Choosing a positioning scheme: 'position' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#choose-position
> In the case of the print media type, the box is fixed with respect to
> the page
If it repeats on every page, then that should be mentioned here.
S9.3.2 Box offsets: 'top', 'right', 'bottom', 'left'
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#choose-position
It seems like the property definitions for top, right, left, and bottom
could be combined into one table+description+note. Other than the name
of the side, the text is exactly the same.
# The offset is a percentage of the containing block's box width
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
change to
containing block's width
# See the sections on the width and height of absolutely positioned,
# non-replaced elements for details
Strike out "non-replaced".
S9.4.1 Block formatting context
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q15
# In a block formatting context, each box's left outer edge touches the
# left edge of the containing block (for right-to-left formatting, right
# edges touch). This is true even in the presence of floats (although a
# box's line boxes may shrink due to the floats).
What about clearance?
S9.10 Text direction: the 'direction' and 'unicode-bidi' properties
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#direction
# For the 'direction' property to have any effect on inline-level
# elements... ^^^^^^^^^^^^^^^^^^
change to
For the 'direction' property affect reordering in inline-level
elements...
~fantasai
From: fantasai (fantasai@escape.com)
Date: 2003-10-21
Archive: http://www.w3.org/mid/3F94F0D9.7060200@escape.com
fantasai wrote: > S9.10 Text direction: the 'direction' and 'unicode-bidi' properties > http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#direction Left out the rest: # For block-level elements this creates an override for inline-level # descendents not within another block. Why does adding a "display: block" to an element in a paragraph all of a sudden obviate the need for a directional override? # In this process, non-textual entities such as images are treated # as neutral characters as object replacement characters (U+FFFC) ~fantasai
From: fantasai (fantasai@escape.com)
Date: 2003-10-21
Archive: http://www.w3.org/mid/3F94ED06.5060006@escape.com
S9.4.3 Relative positioning
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#relative-positioning
# Relative positioning may also be used as a general form of superscripting
# and subscripting except that line height is not automatically adjusted to
# take the positioning into consideration.
change to
Although relative positioning may be used as a form of superscripting and
subscripting, the line height is not automatically adjusted to take the
positioning into consideration.
S9.5 Floats
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats
# The top of the floated box is aligned with the top of the current line
# box (or bottom of the preceding block box if no line box exists).
Are you saying that a float floats over it's parent's top margin+border+padding?
# The margin box of an element in the normal flow that establishes a new
# block formatting context (such as a table, or element with 'overflow'
# other than 'visible') must not overlap any floats in the same block
# formatting context as the element itself. If necessary, implementations
# should clear the said element by placing it below any preceding floats,
# but may place it adjacent to such floats if there is sufficient space.
The margin box of an element in normal flow is always as wide as the
containing block. What is this rule *supposed* to say?
# Example. In the following document fragment, the containing block is
# too short to contain the content
Too narrow, not too short. The /line boxes/ are too short next to the
float; the containing block is wide (and long) enough.
# Formatting would have been exactly the same if the document had been:
...
# because the content to the left of the float is displaced by the float
# and reflowed down its right side.
Poor explanation, imo. Try:
because the float is taken out of the flow from the same line as in
the previous example.
S9.5.1 Positioning the float: the 'float' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#float-position
# It may be set for elements that generate boxes that are not absolutely
# positioned.
It can be set for any element. It just doesn't _apply_ to some of them.
# Same as 'left', but content flows on the left side of the box, starting
# at the top.
No, it's not the same as 'left' because it's floated to the _right_, not
the left.
# References to other elements in these rules refer only to other elements
# in the same block formatting context as the float..
But weren't you just talking about inline elements? (Like in rule 5.)
Inlines don't participate in the block formatting context.
S9.5.2 Controlling flow next to floats: the 'clear' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#flow-control
# The clearance dimension is introduced as a dimension above the
# margin-top of an element that is used to push the element
# vertically (typically downward).
Calling it a dimension doesn't seem quite right. How about
Clearance is introduced as spacing above the margin-top of an
element. It is used to push the element vertically downward,
past the float.
I can't think of any cases where clearance would cause the element
to go up, so "typically" should not be there to imply that there
are some.
# Values have the following meanings when applied to non-floating
# block boxes:
What about floating boxes?
# Example:
#
# span { clear: left }
This example is useless. Take it out.
9.8.3 Floating a box
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q27
The image for these examples imply that all the leading is added
on top of the line. They should depict a 50/50 split in the leading.
# #sibling { clear: right; color: red }
I thought we just established that 'float' does not apply to inline
elements?
S9.8.4 Absolute positioning
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q28
# Relative and absolute positioning may be used to implement change
# bars, as shown in the following example.
# ... the change bars seem to "float" to the left of the current line.
Wouldn't it make more sense to use a float?
(And wouldn't it be better to use a proper em-dash?)
S9.9.1 Specifying the stack level: the 'z-index' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#z-index
# In this section, the expression "in front of" means closer to the
# user as the user faces the screen.
screen -> canvas
# Stacking contexts are not necessarily related to containing blocks.
# In future levels of CSS, other properties may introduce stacking
# contexts, for example 'opacity'.
The first sentence needs an example.
The second sentence should not have one.
# The default behavior of a box is to allow boxes behind it to be
# visible through transparent areas in its content.
The default behavior of the background is...
~fantasai
From: Tex Texin (tex@i18nguy.com)
Date: 2003-10-22
Archive: http://www.w3.org/mid/3F9625D7.CC1F5B19@i18nguy.com
Bert, et al.
Just fyi, The I18n WG had its weekly telecon today and had the opportunity to
begin reviewing the comments I submitted on CSS21.
(Summary to i18nwg: http://www.w3.org/mid/3F9378F2.F5679667@i18nguy.com )
There was general support for them, although the review of my comments will
continue thru next week.
The following was minuted in particular:
"We think that IRIs are really important, section on URI should be updated to
reference IRIs-
CSS should reference RFC 3066 for language codes"
You can expect some additional followup in at least 3 areas:
1) The issue for BOM is also important, and Richard Ishida has an action to
send you more details on our thoughts with respect to BOM and encoding
declarations and defaults.
2) We do not have agreement on the text-transform clipboard issue.
I was recommending that copying to the clipboard should copy text as rendered.
i.e. if it was uppercased on the display, it would be on the clipboard that
way. Others thought the text should be copied as it is cased in the source.
There were use cases for each position. When I have more time and if there is
interest, I'll write them up.
We did all agree that it would be good if CSS prescribed what should happen,
for consistency.
3) There was also discussion of the wording of the conformance requirement for
bidi:
http://www.w3.org/TR/CSS21/visuren.html#direction
"If a document contains right-to-left characters, and if the user agent
displays these characters in right-to-left order, the user agent must apply the
bidirectional algorithm."
As the discussions finish, we'll update you.
I hope that helps,
Regards,
Tex
--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com
Xen Master http://www.i18nGuy.com
XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
From: staffan.mahlen@comhem.se
Date: 2003-10-22
Archive: http://www.w3.org/mid/3F96E580.26593.6A6B1A@localhost
I think i missed the deadline, but i just noticed: http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats # The margin box of an element in the normal flow that establishes a new # block formatting context (such as a table, or ... That 'table' should possibly read table-cell, but i think it makes more sense to update http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q15 to include tables as well. Also, i think it may be a good idea to change the heading "9.4.1 Block formatting context" to "9.4.1 Block formatting contexts" to make it more explicit that there are multiple. /Staffan
From: Christoph Päper (christoph.paeper@tu-clausthal.de)
Date: 2003-10-22
Archive: http://www.w3.org/mid/0aba01c398c7$64f30d70$3ef4ae8b@heim4.tuclausthal.de
Tex Texin <tex@i18nguy.com>:
>
> "We think that IRIs are really important, section on URI should be updated
to
> reference IRIs-
I don't think it should be referenced just yet, because AFAIK it's not an RFC
yet or is ther eanything more recent than
<http://www.ietf.org/internet-drafts/draft-duerst-iri-04.txt>? Btw. I don't
think they're already known by the majority of www-style readers, so why
didn't you give more information on IRIs?
> CSS should reference RFC 3066 for language codes"
Yes, although :lang(C) should IMHO work with any language identification
method known to the implementation, else it would be merely a shorthand for
'[lang|="C"], [xml|lang="C"]' (or is it 'xml:lang'?).
Example:
:lang(en-US) {color: green}
<foo language="english, USA">Text.</foo>
"Text." is green in user agents, that have further knowledge of the ML to map
values of 'language' to RFC 3066 conforming values, which are then used by the
CSS parser.
That's unlikely to happen, but shouldn't be forbidden.
> 2) We do not have agreement on the text-transform clipboard issue.
> I was recommending that copying to the clipboard should copy text as
rendered.
I think that's platform dependent, some may even not have a clipboard nor even
a copy method.
If there is however a copy to clipboard feature, the UA would mark the copied
text
foo {text-transform: capitalize; color: green;}
bar {text-decoration: underlined;}
<foo>Text to <bar>copy</bar>.</foo>
In my perfect world, it becomes, when pasted into a plain text editor:
Text to copy.
in an e-mail composition window without HTML support:
Text to copy.
or
Text To _Copy_.
... with text/enriched support and requested:
<color><param>green</param>Text to <underline>copy</underline>.</color>
... with HTML 3.2:
<font color="green"><u>Text to copy</u></font>
... with HTML4 Strict:
<span style="text-transform: capitalize; color: green">Text to
<span style="text-decoration: underlined">copy</span>.</span>
in an XML editor:
<foo>Text to <bar>copy</bar>.</foo>
and a XML editor with CSS knowledge additionally updates the applicable
stylesheet(s) of the document with
foo {text-transform: capitalize; color: green;}
bar {text-decoration: underlined;}
They all don't change the capitalisation of the characters themselves, except
for the e-mail application that encodes styles with paired ASCII characters
(_*/=) or directly into them (case).
> if it was uppercased on the display, it would be on the clipboard that way.
The clipboard holds some meta format that is interpreted by the pasting
application as good as it can.
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2003-10-27
Archive: http://www.w3.org/mid/200310270540.h9R5ehJv016652@nerd-xing.mit.edu
-- Section 9.1.2 (Containing blocks)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#containing-block>
Does the root element sentence really belong here rather than in the sections
describing those properties?
-- Section 9.2.1 (Anonymous block boxes)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#anonymous-block-level>
The example talks about having a "anonymous block box for BODY". I'm not sure
what this means. Since the BODY is an inline inside a block (HTML), and the
boxes of BODY end up with a block sibling (the P), I would expect an anonymous
block _around_ the BODY boxes. But the boxes of BODY should be inline.
This example should probably be clarified.
The part about being turned into anonymous block boxes that follows the example
is also confusing.... What does it mean for the border of the BODY to apply in
this case? The spec sounds like it should draw two block-like borders -- one
around the anonymous block containing C1, one around the anonymous block
containing C2.
-- Section 9.2.2 (Inline-level elements and inline boxes)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q7>
'inline-block' should be listed as a display type that makes an element inline.
Not done with this yet, but not sure when I'll get to chance to wrap up. :(
Boris
--
"What the hell are you getting so upset about? I
thought you didn't believe in God."
"I don't," she sobbed, bursting violently into
tears, "but the God I don't believe in is a good God, a
just God, a merciful God. He's not the mean and stupid
God you make Him out to be."
--Joseph Heller, "Catch-22"
From: Ian Hickson (ian@hixie.ch)
Date: 2003-10-31
Archive: http://lists.w3.org/Archives/Public/www-style/2003Oct/0360.html
On Tue, 21 Oct 2003, fantasai wrote:
>
> I can't think of any cases where clearance would cause the element
> to go up, so "typically" should not be there to imply that there
> are some.
<block-a><float/></block-a>
<block-b/>
* { border: solid; } /* assume border is present but infinitesimal */
float { height: 3em; }
block-a { margin-bottom: 2em; }
block-b { margin-top: 2em; }
The clearance on block-b is -1em, so the clearance moves the element up
by one em (relative to where it would be if the margins didn't collapse
but the clearance was 0 -- clearance first uncollapses the margins (per
the rules in 8.3.1) and then moves the block relative to where that box
ends up after uncollapsing).
--
Ian Hickson )\._.,--....,'``. fL
U+1047E /, _.. \ _\ ;`._ ,.
http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Bert Bos (bert@w3.org)
Date: 2003-12-24
Archive: http://www.w3.org/mid/3FE9F445.50701@w3.org
-------- Original Message --------
Subject: [Moderator Action] CSS 2.1, section 5.8.2
Date: Tue, 23 Dec 2003 17:29:34 -0500 (EST)
From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
To: www-style@w3.org
CC: W3C XML Coordination Group <w3c-xml-cg@w3.org>
Dear colleagues:
The XML Coordination Group congratulates you on the progress of the
CSS 2.1 specification.
We write you with some concern, however, about one detail of the
specification, which may raise an important inter-Activity
coordination issue.
It has been called to our attention that in section 5.8.2 "Default
attribute values in DTDs" [1], the CSS 2.1 specification is subject to
two different and contradictory readings.
[1] http://www.w3.org/Style/Group/css2-src/diffs-rec/selector.html#q11
The words
Default attribute values may be defined in a DTD or elsewhere, but
cannot always be selected by attribute selectors. Style sheets
should be designed so that they work even if the default values
are not included in the document tree.
may be taken as meaning either
(1) Because not all XML parsers read an external DTD, it will
occasionally be the case that a CSS process does not, in practice,
have access to defaulted attribute values; it is thus wise to take
special steps to ensure that the stylesheet works as desired even
if default attribute values are not accessible to the process.
or
(2) Because not all XML parsers read an external DTD, there will
be cases when CSS processes do not have access to defaulted
attribute values. For this reason, and in order to ensure that
all CSS processors produce identical results even if some use
validating XML parsers and others use processors which ignore the
external DTD even for non-standalone documents, a CSS process is
forbidden to process attributes if the attribute value was
supplied by default from a DTD, schema, or other external
information.
We hope that interpretation (1) is the intended one, and suggest that
the wording of section 5.8.2 be modified to make that interpretation
more explicit, and to rule out interpretation (2). One possible
change might be to modify the first sentence quoted above, while
retaining the second unchanged:
Default attribute values may be defined in a DTD or elsewhere, but
will be available for selection by attribute selectors only if
the XML parser in use processed the DTD or other source of
information. Style sheets should be designed so that they work
even if the default values are not included in the document tree.
We believe it would be a mistake to allow interpretation (2) to take
hold in the implementor or user communities. There are XML
vocabularies which make extensive use of defaulted attributes, and
there are implementations that can do useful things with them; it
would be regrettable were the use of default attributes to be made, in
effect, incompatible with CSS. Equally bad would be the consequence
of making DTD- and schema-aware processors unusable as the upstream
XML parsers for CSS processing. Most such processors do not
distinguish in their output between attributes whose value was
supplied explicitly in the input data stream and attributes whose
value was supplied by default; interpretation (2) would make it
non-conforming for any CSS processor to use such an XML parser. We
think that would be a mistake both because it would needlessly
restrict the choice of XML parser to be made by implementors of CSS,
and because it would work against use of DTDs or schemas in material
intended to be rendered using CSS.
We hope that you will, on reflection, agree that interpretation (1) is
preferable to interpretation (2), and revise the text accordingly.
Please let us know whatever you do.
Respectfully,
C. M. Sperberg-McQueen
on behalf of the XML Coordination Group
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 4 93 65 76 92 06902 Sophia Antipolis Cedex, France
From: Tantek Çelik (tantek@cs.stanford.edu)
Date: 2004-02-05
Archive: http://www.w3.org/mid/BC47273E.3599B%25tantek@cs.stanford.edu
On 3/2/03 4:13 PM, "fantasai" <fantasai@escape.com> wrote: > > CSS2.1 draft, Section 12.2 > http://www.w3.org/TR/2003/WD-CSS21-20030128/generate.html#content > > # normal > # On the :before and :after pseudo-elements, > # this value is the same as 'none'. > # none > # No content is generated. > > The 'none' value is redundant; please take it out. If it's > needed in CSS3, it can be added there--no need to confuse > the issue. > > 'normal' should be defined as follows: > The pseudo-element is not rendered. Accepted. > It should also be renamed to 'auto', as 'auto' means "self"-- No. 'auto' does not mean "self" in the context of CSS. Typically 'auto' means "perform some calculation" (e.g. margin, width, height, top, left, right, bottom), or "do something platform/UA-specific" (e.g. cursor, table-layout). Whereas 'normal' actually means "don't do anything special, just do the usual (normal) thing", which as you say: > is a connotation you'll want in CSS3. Precisely. > In contrast, 'normal' here means little more > than 'default', That's precisely right, and that's exactly the connotation we want, just like the value 'normal' for the properties font-style, font-variant, font-weight, letter-spacing, and word-spacing for example. Though these connotations are not 100% consistent throughout the spec, they are by far the dominant connotations for those terms in CSS, and thus it makes sense for new uses of those terms to be consistent with those dominant connotations. > and it implies that any other value is > "abnormal". ;) To some minor extent that may be true, though no more so than the other than 'normal' values for other properties that accept 'normal'. > If the WG still feels 'normal' is more appropriate than 'auto', > I would *really* like to know why. *formally requests a reply* Bottom line: 'auto' implies more calculation/intelligence/special-behavior as opposed to 'normal' which implies doing less work, doing the usual thing, which precisely reflects what content:normal does. Thanks again for the feedback, Tantek CSS-WG note: Issue 94. Name of initial value of 'content'. Further communication completed.
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47443.397987.150474@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F7B3147.4242.5F08EB@localhost
(and following thread)
The term "based on the content" in 10.6.4 Absolutely positioned,
non-replaced elements is not defined.
In 9.4.1 Block formatting context, paragraph 3 is no longer true
for elements that generate new block formatting contexts but are
still in flow.
Should inline-blocks that contain floats shrink wrap them?
CSS WG response:
Added a section 10.6.7 "'Auto' heights for block formatting context
roots"
In 9.4.1 added ", unless the child establishes a new block
formatting context" to end of paragraph.
Changed titles of some sections, so that inline-blocks clearly
fall under the case where nested floats contribute to the height.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47452.313141.937717@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F7B235B.20958.28A853@localhost
text-decoration...
CSS WG response:
That's the way it was in CSS1.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47516.180523.899733@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F87E607.9030501@escape.com
CSS WG response:
background-position: The following will be dropped: "The
computed value of background-position for the purpose of
inheritance is undefined, since the allowed values on this
property may have different effects in a child element due to
differences in size and position of their respective boxes." (it's
defined now)
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47458.270282.447366@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309282304.h8SN40r2004872@nerd-xing.mit.edu
Section 6.4.4 (Precedence of non-CSS presentational hints) "type"
is not presentational in some cases, but presentational in others
(on <ol>, <ul>, <li>, to be precise).
CSS WG response:
We don't consider TYPE on lists to be presentational the same way
as COLOR or FONT are.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47436.256257.359604@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://lists.w3.org/Archives/Public/www-style/2003Sep/0106.html
CSS WG response:
Change part 4 of the CR exit criteria to read:
4. Features that were not in CSS1 will be dropped (thus reducing the
list of "all" features mentioned above) if two or more
interoperable implementations of those features are not found by
the end of the CR period.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47476.811572.917445@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
Section 5.10 (Pseudo-elements and pseudo-classes)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#pseudo-elements>
Why are "Conforming HTML UAs" exempted from :first-line and
:first-letter? There seems to be no good reason for this.
CSS WG response:
Removed the exemption.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47507.261788.447475@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://lists.w3.org/Archives/Public/www-style/2003Sep/0096.html
CSS WG response:
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q15
The new first paragraph in block formatting context...:
We don't think an example would necessarily be useful. This would
be more useful in a tutorial than a spec.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47433.476395.452258@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.1 (Box Dimensions)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#box-dimensions>
The definition of "box width" given in this section gives me some
pause. The only mentions of the term "box width" in chapters 8-18
of the specification (other than this definition) are:
A) A statement immediately preceding that says that box widths are
explained in a later chapter.
B) Discussion of percent values for left/right (section 9.3.1
Choosing a positioning scheme: 'position' property). The prose
there says these are percentages of the "containing block's box
width"; is it really intended that he containing block's margin's
affect the offset from the padding edge in this case, per the
definition of "box width"?
C) Discussion of min-width/max-width (10.4 Minimum and maximum
widths: 'min-width' and 'max-width'). The prose here says that
these properties constrain "box widths".... except that's not true
according to the Section 8.1 definition of "box width". They
constrain content widths.
D) A reference to "page box width" in chapter 13. This also seems
to want the content width.
CSS WG response:
Removed definition of box width and box height (A).
Changed occurrences B (removed "box").
Used "content width" instead of "box width" (C).
D is referring to the {{page box} width} not the {page {box width}}.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Ian Hickson (ian@hixie.ch)
Date: 2004-02-09
Archive: http://www.w3.org/mid/Pine.LNX.4.58.0402092217060.9897@dhalsim.dreamhost.com
On Mon, 9 Feb 2004, Boris Zbarsky wrote:
>
> I'm afraid that it does not in fact work. Per that grammar, the
> following is a valid stylesheet production:
>
> <!--
> font { color: red } -->
> <!-- div { display: block }
> --> --> --> span { display: inline }
> <!--
>
> which should result in three rules being parsed. That can't really be
> what's intended
Why not?
> and I doubt any UA will implement it that way;
Mozilla and Opera pass that test:
http://www.hixie.ch/tests/adhoc/css/parsing/core-syntax/cdocdc/001.html
...and also a test for the same thing that I wrote in 1998 or so:
http://www.hixie.ch/tests/evil/mixed/cdocdc.html
I don't really understand the problem here.
--
Ian Hickson )\._.,--....,'``. fL
U+1047E /, _.. \ _\ ;`._ ,.
http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47500.745841.146514@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F684CB4.21220.7532AF@localhost
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats
The paragraph is a little vague on how to handle the conflict
between a float and another block that generates a new block
formatting context when they are in the same block formatting
context. Why not require that the box is cleared? When is it
desirable to position it adjacent, creating a kind of a
"pseudo-float"?
CSS WG response:
Because that's what UAs interoperably do, and the adjacent
position is desirable if there is enough room.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47484.197984.890496@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
Section 5.5 (Descendant Selectors)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#descendant-selectors>
This says, in the example: "the whitespace is the descendant
selector indicating..." The whitespace is a combinator which makes
the whole selector a descendant selector, no? Which is not what
that's saying...
CSS WG response:
Text changed: "... the whitespace is a combinator indicating that
the DIV must be the ancestor of..."
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47488.226429.681347@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
Section 4.3.7
<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#strings>
The language Double quotes cannot occur inside double quotes,
unless escaped (as '\"' or as '\22'). is somewhat misleading,
since there are other ways that a quote could be escaped (eg using
\000022).
CSS WG response:
Inserted "e.g.": (*e.g.* as '\"' or as '\22')
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47504.714489.749441@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://lists.w3.org/Archives/Public/www-style/2003Sep/0096.html
"Something i dont understand is why non-initial overflow needs to
generate a new block formatting context?"
CSS WG response:
Floats don't make sense across scrolling boundaries.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-09
Archive: http://www.w3.org/mid/4027D4A5.5020303@mit.edu
Bert Bos wrote:
> Your e-mail:
> http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
>
> Section 5.12.2 (The :first-letter pseudo-element) The last
> paragraph of the example with the floated 'T' says...
>
> CSS WG response:
>
> It may be unclear, but we think it is defined.
Perhaps my issue was unclear.... The current text, as written, is
self-contradictory. As an implementor, I can't tell how this should
work and hence can't implement it.
To be precise, if the "the :first-line pseudo-element start tag is
inserted right after the start tag of the element to which it is
attached" language is correct then given the markup:
<DIV>
<P>First paragraph</P>
<P>Second paragraph</P>
</DIV>
we should get the fictional tag sequence:
<DIV>
<DIV:first-line>
<P><P:first-line>First paragraph</P:first-line></P>
</DIV:first-line>
<P><P:first-line>Second paragraph</P:first-line></P>
</DIV>
and not what the spec has. What the spec has makes a lot more sense, so
the quoted language should probably just be removed or changed to talk
about the start tag of the block element that contains the first line of
the element to which it's attached.
Clarifying this would probably also addressed the other concern I raised
in the same mail.
-Boris
From: L. David Baron (dbaron@dbaron.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/20040209194019.GA6816@darby.dbaron.org
On Monday 2004-02-09 13:22 -0600, Boris Zbarsky wrote: > Bert Bos wrote: > >Your e-mail: > > http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu > > Section 8.1 (Box Dimensions) > > <http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#box-dimensions> > >CSS WG response: > > > > Not a problem since 8.1 is rather vague anyway. > > Given that at least one major browser (IE/Windows) actually implements > this sentence rather literally, I don't see it as being "not a > problem".... A lot of people have the impression that te IE/Windows > behavior is correct, and doing anything to further that impression is > extremely harmful, in my opinion. Agreed. A simple proposal to fix this issue is to change: The content edge surrounds the element's rendered content. to: The content edge surrounds the rectangle given by the width and height of the box, which often depend on the element's rendered content. (Note that "width" and "height" are not links to properties, since that would be inappropriate for some types of boxes, but they could be links to sections 10.3 and 10.6.) -David -- L. David Baron <URL: http://dbaron.org/ >
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47493.492358.743155@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
Section 4.3.4
<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#uri> The
text: Parentheses, commas, whitespace characters, single quotes
(') and double quotes (") appearing in a URI must be escaped with
a backslash: '\(', '\)', '\,'. is misleading,
CSS WG response:
Add "unquoted" before "URI" in that quoted text. Commas are
escaped for future expansion.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47474.310916.815551@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
Section 5.11.1 (:first-child pseudo-class)
<http://www.w3.org/Style/css2-updates/WD-CSS21-20030915-diff/selector.html#first-child>
This needs to define what a "first child" is.
CSS WG response:
Added the word "element" after "first child" in 5.11.1
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47439.784732.980081@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.1 (Box Dimensions)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#box-dimensions>
The description of "content edge or inner edge" makes it sound
like this edge always surrounds the "rendered content"...
CSS WG response:
Not a problem since 8.1 is rather vague anyway.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47497.565605.768575@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
Section 4.1.1
<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#tokenization>
Definition of the "unicode" production does not match Appendix G.
CSS WG response:
Corrected.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47491.180111.711062@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
Section 4.3.4
<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#uri>
What happens if the URI string is not a syntactically valid URI?
CSS WG response:
Add "invalid URIs or" between "handle" and "URIs" in the "user
agents may vary" clause in 4.3.4.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-09
Archive: http://www.w3.org/mid/4027D6C6.5000504@mit.edu
Bert Bos wrote:
> Your e-mail:
> http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
>
> Section 4.1.1... CDO and CDC...
>
> CSS WG response:
>
> It's odd but it works and we're happy with it, so, let's keep it.
I'm afraid that it does not in fact work. Per that grammar, the
following is a valid stylesheet production:
<!--
font { color: red } -->
<-- div { display: block }
--> --> --> span { display: inline }
<!--
which should result in three rules being parsed. That can't really be
what's intended, and I doubt any UA will implement it that way;
unfortunately we'll need a CSS2.1 test suite testcase for this if things
stay as they are (I'm volunteering to take the above and modify it into
a testcase following the suite guidelines if needed).
In my opinion, changing the stylesheet production to:
stylesheet : CDO? [ S | statement ]* CDC?;
would be a big step up. Further specifying that CDO and CDC don't
belong in sheets that are not embedded in a *ML document is still a good
idea, I think....
-Boris
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47467.145644.35114@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
Section 5.12.2 (The :first-letter pseudo-element) The last
paragraph of the example with the floated 'T' says: Note that the
:first-letter pseudo-element tags abut the content (i.e., the
initial character), while the :first-line pseudo-element start tag
is inserted right after the start tag of the element to which it
is attached. I'm not sure what this means,...
CSS WG response:
It may be unclear, but we think it is defined.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47472.101982.551480@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
Section 5.11.3 (The dynamic pseudo-classes: :hover, :active, and
:focus)
<http://www.w3.org/Style/css2-updates/WD-CSS21-20030915-diff/selector.html#dynamic-pseudo-classes>
If an element is hovered, are its ancestors considered hovered?
CSS WG response:
Leaving this undefined for CSS21. Added that whether :hover and
:active apply to ancestors is undefined. Added note at end of
5.11.3 about :active in CSS1 only applying to links.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-09
Archive: http://www.w3.org/mid/4027D1EB.5070006@mit.edu
Bert Bos wrote: > Your e-mail: > http://www.w3.org/mid/200309282315.h8SNFiEh006969@nerd-xing.mit.edu > Section 7.3 (Recognized media types) > <http://www.w3.org/TR/2003/WD-CSS21-20030915/media.html#media-types> > CSS WG response: > > Reworded the text: "names of media types are normative, but the > parenthetical descriptions are informative. Those aren't really parenthetical descriptions; they're just descriptions.... -Boris
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-09
Archive: http://www.w3.org/mid/4027D1AD.6050502@mit.edu
Bert Bos wrote: > Your e-mail: > http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu > Section 4.4 > <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q23> > CSS WG response: > > It's UA dependent (see response to issue 44 for the new text) As I pointed out, the vast majority of stylesheets fall into this category. If we still feel like making this UA-dependent, I'm not going to argue, but this leaves everyone involved (UA implementors and page authors) plenty of rope to hang themselves many times over. -Boris
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47509.532308.973825@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://lists.w3.org/Archives/Public/www-style/2003Sep/0134.html
CSS WG response:
Section 1.4.5: agreed, changed accordingly
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47486.259702.273080@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
Section 4.4 <
http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q23> What
about stylesheets that have a BOM but no @charset rule? Should the
presence of a BOM imply that the sheet is encoded as, eg UTF-8 or
UTF-16LE (if the appropriate BOM is present), as it does for XML?
CSS WG response:
New bullet point added, which allows a UA to infer the charset
from the BOM, if the other ways to find the charset fail:
4. UA-dependent mechanisms (e.g., guessing based on the BOM)
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47464.897110.526868@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309282304.h8SN40r2004872@nerd-xing.mit.edu
Section 6.4.3 (Calculating a selector's specificity) The spec
says: li:first-line {} /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,2
*/ It should say d=2 here.
CSS WG response:
Corrected.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47449.480503.679534@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/Pine.GSO.4.58.0310020923540.11649@korppi.cs.tut.fi
text-decoration... should be deprecated.
CSS WG response:
We do not see any reason to deprecate.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47455.464079.962636@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309282315.h8SNFiEh006969@nerd-xing.mit.edu
Section 7.3 (Recognized media types)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/media.html#media-types>
What does "The names of media types are normative" mean? What
should a UA do when encountering an @media or @import rule that
lists an unknown media type?
CSS WG response:
Reworded the text: "names of media types are normative, but the
parenthetical descriptions are informative.
Also added: "Unknown media type identifiers should not result in
the @media rule being ignored."
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47519.552017.332738@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F684CB4.21220.7532AF@localhost
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats As
an editorial comment i noticed that the phrase "block formatting
context" was only occationally linked to its defintion, in case
this is not intentional.
CSS WG response:
Updated in some places.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-09
Archive: http://www.w3.org/mid/402811FA.8010105@mit.edu
Ian Hickson wrote: > Mozilla and Opera pass that test: Hmm... Indeed, they do. I clearly should have done my research a bit better... :( I'm still not happy with this on general grounds (it seems like a very random thing to allow in the grammar), but given that UAs already work this way I withdraw my objections. -Boris
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47469.609757.962247@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
Section 5.12.2 (The :first-letter pseudo-element)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-letter>
'float' is not listed as a propety that applies to :first-letter
pseudo-elements.
CSS WG response:
Corrected.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47481.705244.729423@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
Section 4.4
<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q23>
Another point is that it's trivial to have a stylesheet for which
steps 1, 2, 3 will give no useful charset value.
CSS WG response:
It's UA dependent (see response to issue 44 for the new text)
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-09
Archive: http://www.w3.org/mid/4027DDFA.7090700@mit.edu
Bert Bos wrote: > Your e-mail: > http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu > Section 8.1 (Box Dimensions) > <http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#box-dimensions> > CSS WG response: > > Not a problem since 8.1 is rather vague anyway. Given that at least one major browser (IE/Windows) actually implements this sentence rather literally, I don't see it as being "not a problem".... A lot of people have the impression that te IE/Windows behavior is correct, and doing anything to further that impression is extremely harmful, in my opinion. -Boris
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-09
Archive: http://www.w3.org/mid/4027D14A.6090707@mit.edu
> Your e-mail: > http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu > Section 4.4 < > http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q23> What > > New bullet point added, which allows a UA to infer the charset > from the BOM, if the other ways to find the charset fail: > > 4. UA-dependent mechanisms (e.g., guessing based on the BOM) Isn't guessing based on the BOM more reliable than using the charset from the language of the referencing document? The former is part of the sheet itself, while the latter is an external reference that can get out of sync... -Boris
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47479.358400.437258@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
Section 4.1.1... CDO and CDC...
CSS WG response:
It's odd but it works and we're happy with it, so, let's keep it.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47460.927696.499175@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309282304.h8SN40r2004872@nerd-xing.mit.edu
Section 6.4.4 (Precedence of non-CSS presentational hints) Why is
"dir" not considered a presentational hint?
CSS WG response:
Because it is structural.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47495.436082.810858@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
Section 4.1.1
<http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#tokenization>
Is it intended that '_' be a valid "ident" production?
CSS WG response:
It's odd but it works and we're happy with it, so, let's keep it.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47511.546847.222294@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://lists.w3.org/Archives/Public/www-style/2003Sep/0134.html
CSS WG response:
Section 1.4.2: changed to; "For example, the 'clear' property only
affects block-level elements."
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-09
Archive: http://www.w3.org/mid/4027D22B.7040706@mit.edu
Bert Bos wrote: > Your e-mail: > http://www.w3.org/mid/200309282304.h8SN40r2004872@nerd-xing.mit.edu > > Section 6.4.4 (Precedence of non-CSS presentational hints) "type" > is not presentational in some cases, but presentational in others > (on <ol>, <ul>, <li>, to be precise). > > CSS WG response: > > We don't consider TYPE on lists to be presentational the same way > as COLOR or FONT are. Why not, exactly? If it's not presentational, why is there a CSS property that has the same effect? -Boris
From: Bert Bos (bert@w3.org)
Date: 2004-02-09
Archive: http://www.w3.org/mid/16423.47446.538444.910079@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/Pine.GSO.4.58.0310012037070.20874@korppi.cs.tut.fi
text-decoration... replaced by bottom-border
CSS WG response:
It was in CSS1 and is heavily used.
See also http://www.w3.org/mid/3F7B596C.2060902@escape.com
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-10
Archive: http://www.w3.org/mid/16425.21857.420099.432694@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.3.6 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#color-units>:
# The format of an RGB value in the functional notation is 'rgb('
# followed by a comma-separated list of three numerical values (either
# three integer values or three percentage values) followed by ')'.
Is rgb(255, 0, 50%) invalid, then?
CSS WG response:
Yes. (Was already like that in CSS1.)
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-10
Archive: http://www.w3.org/mid/16425.21854.733108.683783@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.3.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#length-units>:
# In cases where the computed length cannot be supported, user agents
# must approximate it in the actual value.
^^^^^^^^^^^^
Actual values haven't been defined at this point. Maybe link to
the appropriate section?
CSS WG response:
Linked.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-10
Archive: http://www.w3.org/mid/16425.21852.427012.28881@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
fantasai <fantasai@escape.com>
S4.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#parsing-errors>:
# Malformed declarations. User agents must handle unexpected tokens
# encountered while parsing a declaration by reading until the end
# of the declaration, while observing the rules for matching pairs
# of (), [], {}, "", and '', and correctly handling escapes.
I can't seem to find "the rules for matching pairs of (), [],
{}, "", and ''".
CSS WG response:
4.1.8, for example. No change.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-10
Archive: http://www.w3.org/mid/16425.21847.694241.729068@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.1.9 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#comments>:
# CSS also allows the SGML comment delimiters ("<!--" and "-->") in
# certain places, but they do not delimit CSS comments. They are
# permitted so that style rules appearing in an HTML source document
# (in the STYLE element) may be hidden from pre-HTML 3.2 user agents.
# See the HTML 4.0 specification ([HTML40]) for more information.
It says SGML comment delimiters are allowed "in certain places".
Very mysterious-like, especially considering the amount of detail
about HTML. Why not say where exactly? And why is the definitive
CSS document referring to the HTML 4.0 spec for details about CSS
syntax? Or is the "more information" more information about hiding
from pre-HTML 3.2 user agents, not "more information" about, like,
where the comment delimiters may be placed?
CSS WG response:
Changed text to say "in certain places _defined by the grammar_"
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Ian Hickson (ian@hixie.ch)
Date: 2004-02-10
Archive: http://www.w3.org/mid/Pine.LNX.4.58.0402101410250.25633@dhalsim.dreamhost.com
On Tue, 10 Feb 2004, Bjoern Hoehrmann wrote: > I object to this resolution. The operative Process document clearly > outlaws such general statements and even if it were allowed, if the > Working Group is not convinced that any feature of the document will > get interoperably implemented, the document is clearly not mature > enough to issue a call for implementations. The question is not whether the working group thinks that implementations of the spec are technically feasible or not -- the working group is just ensuring that if a feature isn't implemented, CSS will not exit CR with that feature, since doing so would be of very little use for authors. > It is, for example, not acceptable for web authors to be presented as > CSS 2.1 Recommendation without positioning, the :hover pseudo-class or > media specific style sheets; ...because authors are happily using them in multiple browsers already? If the implementations are interoperable, then the feature won't be removed -- if the feature is not interoperable, then authors aren't referring to the spec anyway (at least not successfully) so there is no point the spec existing for those features. > the Recommendation would be of no use to them if these features > get dropped and hence they would formally object to the advancement of > the Candidate Recommendation anyway. The Recommendation would be of no use to them if it described features they could not use, or worse, could use but not as described by the spec. > no such features, in which case missing interoperable implementations > just demonstrate that there is something wrong with the specification > that requires a substantive change in order to get fixed, in which > case the document must go back to Working Draft status anyway. There is a third case, the much more common case: implementations either have simply not gotten around to implementing the feature, or implementations were written with poor code or inadequate testing and thus a perfectly fine section of the spec was implemented incorrectly. > I would also like to point out that changing only part four of the > proposed exit criteria would not have been satisfactory anyway, my > original issue was about part four and three. The other part states that features that have not been adequately tested will be dropped. Are you seriously suggesting that you would want features that have not received adequate interoperability testing to remain in the specification? Isn't that violating the spirit of the process document (and the whole _point_ of a CR stage) much more than the given criteria? -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Bert Bos (bert@w3.org)
Date: 2004-02-10
Archive: http://www.w3.org/mid/16425.21820.894632.976802@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.2 (Example of margins, padding, and borders)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#mpb-examples>
"The height of each LI box is given by its content height, plus
top and bottom padding, borders, and margins." What does that
mean, exactly?
CSS WG response:
It's only an example. No change.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-10
Archive: http://www.w3.org/mid/16425.21835.556302.689718@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.5.4 (Border shorthand properties: 'border-top',
'border-bottom', 'border-right', 'border-left', and 'border')
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#border-shorthand-properties>
The heading should list top, right, bottom, left in that order,
probably.
CSS WG response:
Not changed.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bjoern Hoehrmann (derhoermi@gmx.net)
Date: 2004-02-10
Archive: http://www.w3.org/mid/403fab30.584920010@smtp.bjoern.hoehrmann.de
* Bert Bos wrote: >Your e-mail: > http://lists.w3.org/Archives/Public/www-style/2003Sep/0106.html > >CSS WG response: > > Change part 4 of the CR exit criteria to read: > 4. Features that were not in CSS1 will be dropped (thus reducing the > list of "all" features mentioned above) if two or more > interoperable implementations of those features are not found by > the end of the CR period. I object to this resolution. The operative Process document clearly outlaws such general statements and even if it were allowed, if the Working Group is not convinced that any feature of the document will get interoperably implemented, the document is clearly not mature enough to issue a call for implementations. It is, for example, not acceptable for web authors to be presented as CSS 2.1 Recommendation without positioning, the :hover pseudo-class or media specific style sheets; the Recommendation would be of no use to them if these features get dropped and hence they would formally object to the advancement of the Candidate Recommendation anyway. Either there are specific features that require implementation experience to determine whether they can be included in the Rec, in which case these features must be precisely identified, or there are no such features, in which case missing interoperable implementations just demonstrate that there is something wrong with the specification that requires a substantive change in order to get fixed, in which case the document must go back to Working Draft status anyway. I would also like to point out that changing only part four of the proposed exit criteria would not have been satisfactory anyway, my original issue was about part four and three. regards.
From: Bert Bos (bert@w3.org)
Date: 2004-02-10
Archive: http://www.w3.org/mid/16425.21844.920400.9373@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.1.7 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q10>:
# A rule set (also called "rule") consists of a selector followed by
# a declaration block.
What you're saying here is that a "rule" is also a "set of
rules"... declaration block...
CSS WG response:
Maybe for CSS3... Not changed.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: staffan.mahlen@comhem.se
Date: 2004-02-10
Archive: http://www.w3.org/mid/40293751.19528.946EC7@localhost
On 9 Feb 2004 at 17:47, Bert Bos wrote:
> CSS WG response:
>
> Because that's what UAs interoperably do, and the adjacent
> position is desirable if there is enough room.
>
While i must admit to more or less agreeing to the first part of the
above sentence, i don't quite understand the second. For instance,
what users intuitively expect the following should render like it
does?
<table align="left">
<tr><td>First</td></tr>
</table>
<table align="center">
<tr><td>Second</td></tr>
</table>
<table align="right">
<tr><td>Third</td></tr>
</table>
If you play around a little, you do get interoperability issues, but
that may be due to the bugs in table and float implementations rather
than issues with the model.
The above is really not all that interesting, but if you get some
spare time, i would like help understanding why this is ever
desirable.
/Staffan
From: Bert Bos (bert@w3.org)
Date: 2004-02-10
Archive: http://www.w3.org/mid/16425.21831.313768.129260@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.4 (Padding properties: 'padding-top', 'padding-right',
'padding-bottom', 'padding-left', and 'padding')
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#padding-properties>
Unlike margin and border, conforming HTML user agents _do_ have to
apply padding to <html>?
CSS WG response:
Yes.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bjoern Hoehrmann (derhoermi@gmx.net)
Date: 2004-02-10
Archive: http://www.w3.org/mid/40421333.611546407@smtp.bjoern.hoehrmann.de
* Ian Hickson wrote: >The other part states that features that have not been adequately tested >will be dropped. Are you seriously suggesting that you would want features >that have not received adequate interoperability testing to remain in the >specification? Isn't that violating the spirit of the process document >(and the whole _point_ of a CR stage) much more than the given criteria? The Process document requires to precisely identify features considered at risk to ensure that the Proposed Recommendation does not invalidate an individual's review or implementation experience of the Candidate Recommendation. A technical report should not advance within the Recommendation track without further work if the Working Group is not able to demonstrate that each feature of the technical report has been implemented. The proposed exit criteria allow dropping features just for the sake of advancement. I do not want to say that this is the intent of the proposed exit criteria, my point is just that a Working Group should not have a blank check to do so. If implementors have simply not gotten around to implement a perfectly fine section of the specification, the perfectly fine section should not get dropped, the Working Group should rather wait with its request for advancement; it may also request advancement without demonstrating implementation experience. The Working Group should encourage complete implementations of the technical report, the proposed exit criteria however do not do so; it does not seem unreasonable for implementors to expect that the Working Group drops the features they do not implement and they would still conform to the specification. If it is forseeable that the exit criteria will not be met due to a specific feature, it would also be reasonable to go back to Last Call with the feature removed, demonstrate implementations and request advancement of the technical report, without losing time or considerable additional work. The difference is that reviewers would have a chance to object to the removal of the feature, as they would have if the exit criteria precisely identify features considered at risk, which is all I have asked for.
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-10
Archive: http://www.w3.org/mid/4029694D.4030101@mit.edu
Bert Bos wrote: > Section 8.5.4 (Border shorthand properties: 'border-top', > 'border-bottom', 'border-right', 'border-left', and 'border') > <http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#border-shorthand-properties> > The heading should list top, right, bottom, left in that order, > probably. > > CSS WG response: > Not changed. Again, may I inquire why? The top-right-bottom-left order is the standard order for all side-related things in CSS; listing things in a different order is very confusing to readers, who then waste time trying to figure out why the order was changed in this one instance. Is there a good reason to keep the order as-is? Or is the goal to avoid unnecessary changes? (I can sympathize with that, for extensive changes, but this change just involves swapping "right" and "bottom" there....) -Boris
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-10
Archive: http://www.w3.org/mid/402968C8.8050807@mit.edu
> Unlike margin and border, conforming HTML user agents _do_ have to > apply padding to <html>? > > CSS WG response: > Yes. May I ask why? Pardon the frankness, but that's a pretty wacky thing to require (or allow, depending on the viewpoint). Either <html> is special and <body> is treated as the root, or <html> is just a block, I would think.... Which particular quirk in which particular UA are we catering to, and why? -Boris
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-10
Archive: http://www.w3.org/mid/4029683C.5050304@mit.edu
> Your e-mail: > http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu > Section 8.2 (Example of margins, padding, and borders) > <http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#mpb-examples> > "The height of each LI box is given by its content height, plus > top and bottom padding, borders, and margins." What does that > mean, exactly? > > CSS WG response: > It's only an example. No change. What's the point of having incorrect or misleading examples? Enough people are confused about what "height" means in CSS without examples like this to confuse them further (and the people involved are exactly the ones who would read the examples but not any of the rest of the spec). Essentially, the term "height" as used in that sentence is completely meaningless (it's not used in quite that fashion anywhere else in the spec). Please replace it with a term like "box height" or something and define that term carefully. -Boris who is tired of people filing bugs after reading such examples
From: Bert Bos (bert@w3.org)
Date: 2004-02-10
Archive: http://www.w3.org/mid/16425.21839.732821.339942@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F81EB3F.5020400@escape.com
These two sentences are in conflict:
S4.1.3 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q6>:
# In CSS 2.1, identifiers... cannot start with a hyphen or a digit.
S4.1.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q4>:
# In CSS2.1, identifiers may begin with '-' (dash) or '_' (underscore).
CSS WG response:
Struck "a hyphen or" from 4.1.3.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-10
Archive: http://www.w3.org/mid/16425.21850.243743.700512@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
fantasai <fantasai@escape.com>
S4.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#parsing-errors>:
# Malformed declarations. User agents must handle unexpected tokens
# encountered while parsing a declaration by reading until the end
# of the declaration, while observing the rules for matching pairs
# of (), [], {}, "", and '', and correctly handling escapes.
What happens if there's a mismatched bracket?
elem {pro[perty: value; }
CSS WG response:
Added "How to handle unparseable and untokenisable
stylesheets is undefined in CSS2.1." in section 4.1.1.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-10
Archive: http://www.w3.org/mid/16425.21827.40104.443466@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.3.1 (Collapsing margins)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html> "Collapsing
is based on the computed value of 'padding', 'margin', and
'border'." The computed value of margin properties is "the
percentage as specified or the absolute length". What exactly does
it mean for collapsing be based on the computed value if that can
be "the percentage as specified"?
CSS WG response:
Changed "computed" to "used". ("Used" is a new term, defined
separately.)
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37569.461545.515893@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
Link Pseudo-Classes
S5.11.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#link-pseudo-classes>
# Note. It is possible for stylesheet authors to abuse the :link and
# :visited pseudo-classes to determine which sites a user has visited
# without the user's consent. UAs may therefore treat all links as
# unvisited links, or implement other measures to preserve the user's
# privacy while rendering visited and unvisited links differently. See
# [P3P] for more information about handling privacy.
If you want to let UAs treat all links as unvisited, then put that in
the normative prose, not an informative note. As for privacy concerns
over :visited and :link, putting that kind of a note in here seems
like overkill to me.
CSS WG response:
Split note at "UAs may", second paragraph being normative.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37645.787588.959654@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
Adjacent Elements
S5.7 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#adjacent-selectors>:
# In some contexts, adjacent elements generate formatting objects
# whose presentation is handled automatically (e.g., collapsing
# vertical margins between adjacent boxes). The "+" selector
# allows authors to specify additional style to adjacent elements.
This paragraph is confusing and, imo, useless. Take it out.
CSS WG response:
Paragraph removed.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37624.649974.828010@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
Class Selectors
S5.8.3 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#class-html>:
Also, you need to make clear that an XML namespace may choose as its
class attribute an attribute with a name other than "class".
# Note. CSS gives so much power to the "class" attribute, that authors
# could conceivably design their own "document language" based on
# elements with almost no associated presentation (such as DIV and
# SPAN in HTML) and assigning style information through the "class"
# attribute. Authors should avoid this practice since the structural
# elements of a document language often have recognized and accepted
# meanings and author-defined classes may not.
You tell authors here what not to do with classes. One reads this
warning, but then what? There's no advice on what *to* do! Tantek's
post "A Touch of Class" [1] explains classes particularly well; adding
a few key points from that would turn this block into a more useful
redirect.
[1] http://tantek.com/log/2002/12.html#L20021216t2238
CSS WG response:
Not necessary in a spec. Better in a tutorial.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bjoern Hoehrmann (derhoermi@gmx.net)
Date: 2004-02-11
Archive: http://www.w3.org/mid/40329701.710824902@smtp.bjoern.hoehrmann.de
* Bert Bos wrote:
>Your e-mail:
> http://www.w3.org/mid/3F875337.6080406@escape.com
> :first-line
> # The :first-line pseudo-element can only be attached to
> # a block-level element.
> elem { display: block; }
> elem:first-line { color: blue; }
> elem.special { display: inline; }
> say what?
>
>CSS WG response:
> We don't see the issue.
Pseudo-elements are attached to element type selectors or the universal
selector; neither of them has a notion of beeing block-level, hence the
attachment of pseudo-elements cannot be constraint to this notion. From
<http://www.w3.org/mid/3f3fbed2.307705026@smtp.bjoern.hoehrmann.de>
(member-only):
[...]
And there is "The :first-line pseudo-element can only be attached to a
block-level element". It is not clear what this means with respect to
conformance. If ::first-line is attached to a non-blocklevel element,
does this restriction mean that a user agent must not apply the
styles? For example,
<style type="text/css">
td:first-line { color: green }
</style>
<table>
<tr>
<td>Shall this be green?</td>
<td>Shall this be green?</td>
</tr>
</table>
Both cells are green in IE6, Opera 7.11 and Mozilla 1.3a.
[...]
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37679.742180.198872@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F833074.32375.922D24@localhost
Vertical-align... tall element
CSS WG response:
CSS does not fully describe the result if the tallest element in
the line is not the root of the line. Left undefined for CSS 2.1.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37648.184183.752748@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
Preceding Siblings
S5.1 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#q1>:
# E + F Matches any F element immediately preceded by an element E.
preceded by a _sibling_ element, you mean; E + F shouldn't match if
E is the parent of F.
CSS WG response:
Word "sibling" added.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37654.967152.718209@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/Pine.GSO.4.58.0310092216090.16941@korppi.cs.tut.fi
clarify how to ignore default attributes
CSS WG response:
Made irrelevant by the new text added for issue 77.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: L. David Baron (dbaron@dbaron.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/20040211214355.GA4740@darby.dbaron.org
On Wednesday 2004-02-11 22:23 +0100, Bjoern Hoehrmann wrote:
> * Bert Bos wrote:
> >Your e-mail:
> > http://www.w3.org/mid/3F875337.6080406@escape.com
> > :first-line
> > # The :first-line pseudo-element can only be attached to
> > # a block-level element.
> > elem { display: block; }
> > elem:first-line { color: blue; }
> > elem.special { display: inline; }
> > say what?
> >
> >CSS WG response:
> > We don't see the issue.
>
> Pseudo-elements are attached to element type selectors or the universal
> selector; neither of them has a notion of beeing block-level, hence the
The quoted text is not about selector syntax. It says where the
pseudo-element can be created. Writing a selector doesn't *make* a
pseudo-element. The pseudo-element is a weird thing somewhere in the
area of the document tree or rendering tree (the text of the spec quoted
above suggests that it is "attached" to an element). Its computed style
(and perhaps whether it exists or not) comes from any selectors that
match it.
(As far as I can tell, this is just a more advanced form of the same
misconception that leads people to say "creating a class" when they mean
"writing a selector that matches an element with a class".)
-David
--
L. David Baron <URL: http://dbaron.org/ >
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37547.537036.500848@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
:first-line
This entire section takes the "fictional tag sequence" idea
a bit too literally. For example,
# the user agent could generate the appropriate start and
# end tags for SPAN when inserting the fictional tag
# sequence for :first-line.
No. You can't make the tags real, because then you wind up
with an obscure box model. Suppose, for example, I specify
span { border: 1px solid}. The border shouldn't indicate a
split in the span element at the end of the first line.
CSS WG response:
Changed to: "the user agent could simulate start and end tags for
SPAN when inserting the fictional tag sequence for :first-line."
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37542.615858.972672@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
:first-line
# The :first-line pseudo-element can only be attached to
# a block-level element.
elem { display: block; }
elem:first-line { color: blue; }
elem.special { display: inline; }
say what?
CSS WG response:
We don't see the issue.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37561.542861.860475@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
Dynamic Pseudos
S5.11.3 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#dynamic-pseudo-classes>:
# Similarly, because A:active is placed after A:hover,
# the active color (lime) will apply when the user both
# activates and hovers over the A element.
will apply -> will take effect
CSS WG response:
Not important enough. No change.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37630.476743.541538@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
Default Attributes
S5.8.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#q11>
# EXAMPLE { /*... default property settings ...*/ }
# Because this selector is less specific than an attribute selector,
# it will only be used for the default case.
This is false. The selector will be used for all cases, not just the
default case. If a declaration from this rule conflicts with one from
a more specific rule, then it will be overridden--but the declaration
still applies.
CSS WG response:
It's only an example and is accurate enough, we think. (We
couldn't come up with better text that didn't sound stilted.)
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37573.602435.944412@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
Link Pseudo-Classes
S5.11.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#link-pseudo-classes>
# For example, in HTML 4.0, the link pseudo-classes apply to A
# elements with an "href" attribute.Thus, the following two CSS 2.1
# declarations have similar effect:
#
# a:link { color: red }
# :link { color: red }
This example seems a bit pointless. If it's got a point, you need to
point it out. Otherwise, take it out.
CSS WG response:
Not removed.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37527.731396.902293@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F879634.2070002@escape.com
:first-letter
S5.12.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-letter>
What about punctuation immediately following the first letter?
(three examples included)
CSS WG response:
Text changed:
Punctuation (i.e, characters defined in Unicode [UNICODE] in the
"open" (Ps), "close" (Pe), "initial" (Pi). "final" (Pf) and
"other" (Po) punctuation classes), that precedes or follows the
first letter should be included
And added:
The ':first-letter' also applies if the first letter is in fact
a digit, e.g., the "6" in "67 million dollars is a lot of
money."
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bjoern Hoehrmann (derhoermi@gmx.net)
Date: 2004-02-11
Archive: http://www.w3.org/mid/4033a557.714495009@smtp.bjoern.hoehrmann.de
* L. David Baron wrote: >> Pseudo-elements are attached to element type selectors or the universal >> selector; neither of them has a notion of beeing block-level, hence the > >The quoted text is not about selector syntax. It says where the >pseudo-element can be created. Interesting. I'd rather say that pseudo-elements *select* something that already exists (if it exists) and hence "attaching" pseudo-elements can only be something at the selector syntax level. >(As far as I can tell, this is just a more advanced form of the same >misconception that leads people to say "creating a class" when they mean >"writing a selector that matches an element with a class".) That's actually a quite accurate statement, since they invent (create) a new class (name), add it to the document and then use it to attach properties... A misconception though.
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37616.275344.863349@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
:first-child
S5.11.1 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-child>:
# Note that since anonymous boxes are not part of the document tree,
# they are not counted when calculating the first child.
-Boxes- are never part of the document tree. You mean to say that
"non-element nodes" are not counted.
CSS WG response:
Not changed.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37618.894485.318065@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
ID Selectors
S5.9 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#class-html>:
# Document languages may contain attributes that are declared to be of
# type ID. What makes attributes of type ID special is that no two
# such attributes can have the same value; whatever the document
# language, an ID attribute can be used to uniquely identify its
# element...
Since CSS could conceivably be used for a non-SGML-based document
language, I suggest defining IDs as "unique identifiers" first and
relating them to type ID later. Another advantage is that you start
the definition with generic English rather than specific code.
CSS WG response:
Not a problem currently. Will fix it in Selectors when it
is a problem.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37683.552491.628269@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F833074.32375.922D24@localhost
Vertical-align... top & bottom
CSS WG response:
Added a paragraph to define "aligned subtree":
The following values align the element relative to the line box.
Since the element may have children aligned relative to it (which
in turn may have descendants aligned relative to them), these
values use the bounds of the aligned subtree. The <dfn>aligned
subtree</dfn> of an inline element contains that element and the
aligned subtrees of all children inline elements whose computed
'vertical-align' value is not 'top' or 'bottom'. The top of the
aligned subtree is the highest of the tops of the boxes in the
subtree, and the bottom is analogous.
Changed definitions:
'top'
Align the top of the aligned subtree with the top of the line
box.
'bottom'
Align the bottom of the aligned subtree with the bottom of the
line box.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37552.623636.748989@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
Dynamic Pseudos
S5.11.3 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#dynamic-pseudo-classes>:
# An element can be both ':visited' and ':active' (or ':link' and
# ':active') and the normal cascading rules determine which properties
# apply.
which _style declarations_ apply
CSS WG response:
Changed.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37538.30428.363450@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
:first-line
# A UA should act as if the fictional start tag of the
# first-line pseudo-element is just inside the smallest
# enclosing block-level element.
What do you mean, the "smallest enclosing block-level
element"?
If you're trying to say something about nesting (I'm
guessing based on the example), then *say* something
about nesting. E.g.
:first-line pseudo-elements are nested in the
same order as the elements themselves.
CSS WG response:
"smallest" becomes "inner-most".
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37669.140608.891338@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/4.3.2.7.2.20031008173446.01709bf8@172.27.10.30
http://www.w3.org/mid/200310131858.36221.roger.larsson@incrementa.se
http://www.w3.org/mid/69421B63-FE02-11D7-8E9F-003065B8CF0E@iki.fi
http://www.w3.org/mid/3FE9F445.50701@w3.org
CSS WG response:
New text reads:
Matching takes place on attribute values in the document tree.
Default attribute values may be defined in a DTD or elsewhere,
but cannot always be selected by attribute selectors. Style
sheets should be designed so that they work even if the default
values are not included in the document tree.
More precisely, a UA is not required to read an "external
subset" of the DTD but is required to look for default attribute
values in the document's "internal subset." (See [XML10] for
definitions of these subsets.)
A UA that recognizes an XML namespace [XMLNAMESPACES] is not
required to use its knowledge of that namespace to treat default
attribute values as if they were present in the document. (E.g.,
an XHTML UA is not required to use its built-in knowledge of the
XHTML DTD.)
Note that, typically, implementations choose to ignore
external subsets. Added text to the effect of:
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-11
Archive: http://www.w3.org/mid/16426.37635.74088.759403@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F875337.6080406@escape.com
Attribute Selectors
S5.8 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#attribute-selectors>:
# CSS 2.1 allows authors to specify rules that match attributes
# defined in the source document.
Given the way "matches" is defined in section 5.1, this
sentence should be reworded. The selector doesn't match
the attribute, it matches the element *with* the attribute.
CSS WG response:
Changed to "... match _elements which have certain_ attributes"
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61617.358134.824929@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F8E6343.710045EE@i18nguy.com
# ...consider the value of 'text-transform' to be 'none' for
# characters that are not from the Latin-1 repertoire and for elements
# in languages for which the transformation is different from that
# specified by the case-conversion tables of ISO 10646 ([ISO10646]).
b) From an international perspective, I don't see why you mention
latin-1 at all. Why should latin-2 users for example not have the
benefit of text-transform? Why not simply require support for the
10646 case conversion table, since Unicode character support is
more generally required elsewhere? Given everything else needed to
implement CSS, the Unicode case conversion table seem to be a very
small burden to implementers.
CSS WG response:
See 126.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61985.10618.475287@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
# Since it has no parent, the root of the document tree... if necessary.
Take this paragraph out; this case is already handled by the rules
above it.
CSS WG response:
Removed.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.62019.448022.354941@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
# However, some properties may define the computed value of a property
# for an element to depend on whether the property applies to that element.
This sentence serves no purpose here and therefore is just
confusing. Take it out.
CSS WG response:
No change.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61156.117066.137985@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F879634.2070002@escape.com
:first-letter
S5.12.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-letter>
And what of numbers? They're not letters, but...
(example included)
CSS WG response:
Specified that first digit is matched by :first-letter as well.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61646.738425.165664@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F90EEA2.D954C4FB@i18nguy.com
In both descriptions of the border properties "value:, the color
is listed as border-top-color instead of border-color.
See also: http://www.w3.org/mid/3F90F357.90204@mit.edu
http://www.w3.org/mid/3F91919C.B11E5F0A@i18nguy.com
http://www.w3.org/mid/oprw9kt7boou6nf2@smtp.ozforces.com.au
CSS WG response:
No change.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61783.798263.570191@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
9.10 Text direction: the 'direction' and 'unicode-bidi' properties
"This seemingly one-sided requirement reflects the fact that,
although not every Hebrew or Arabic document contains
mixed-directionality text, such documents are much more likely to
contain left-to-right text (e.g., numbers, text from other
languages) than are documents written in left-to-right languages."
Probably what is meant is that dominantly RTL documents are more
likely to contain LTR parts than dominantly LTR documents are to
contain RTL parts.
CSS WG response:
Quoted text removed.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61678.548315.836995@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
Links to non-normative versions
I suggest providing the diff between CSS 2 and CSS 2.1 with the
final REC and linking to it.
CSS WG response:
We agree.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61404.249580.528039@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
The section 4.3.7 on strings introduces \A for newline and points
to an example, so I assume there isn't a section describing other
backslash codes (e.g. \t etc.). However, the section doesn't
define what the user should do if they actually want a linefeed.
Is \0A (not \A) supposed to generate a linefeed or a newline? In
other words, is that string "\A" a special string, or is the
character code U+000A mapped to linefeed in css? The parenthetical
remark seems to indicate that CSS redefines the Unicode character.
CSS WG response:
\0A and \A are the same. The paragraph now reads:
A string cannot directly contain a newline. To include a newline
in a string, use an escape representing the line feed character
in Unicode (U+000A), such as "\A" or "\00000a". This character
represents the generic notion of "newline" in CSS. See the
'content' property for an example.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61709.395845.960931@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
The definition for "ignore" says there are three meanings.
However, it only list meetings introduced by "First" and "Second".
CSS WG response:
Fixed.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61757.498724.869424@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
8.6 The box model for inline elements in bidi context
No definition is given for the term "bidi context".
CSS WG response:
change "bidi context" to "bidirection context"
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61631.463079.938187@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F8E6343.710045EE@i18nguy.com
[text-transform]
The reference to 2070 should be upgraded to rfc 3066.
CSS WG response:
Updated.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61810.726486.6718@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
12.3.1 Specifying quotes with the 'quotes' property
"Note. While the quotation marks specified by 'quotes' in the
previous examples are conveniently located on computer keyboards,
high quality typesetting would require different ISO 10646
characters." I think it would be better to use the high quality
alternatives in the examples.
CSS WG response:
No change performed. Experts will disagree on what
"high-quality" typesetting is, and the glyphs are likely to be
unavailable in many fonts.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61723.920063.87334@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
4.3.2 Lengths
I suggest calling "absolute" units "physical" instead, because
people tend to consider pixels absolute in the context of computer
graphics.
CSS WG response:
We appreciate your input but not changed.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61695.481340.533007@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
3.1 Definitions
"Element" is defined using a normative reference to SGML. The SGML
standard is not freely available on the Web. Considering that the
SGML specification is not available for linking and reading on the
Web, I suggest removing the normative reference to SGML and
defining "element" by reference to XML instead.
CSS WG response:
Doesn't seem a problem.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61971.778093.329173@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
S6.1.1: Specified values
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#specified-value
# User agents must first assign a specified value to a property...
to _each_ property
CSS WG response:
Changed.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61882.228425.733542@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
15.2 Font matching algorithm
I think the specification is too detailed here. When the page
isn't displayed with the font the author primarily wanted, do this
specifics of the font matching really matter? For example, on Mac
OS X ATSUI already implements a font matching algorithm which
could be considered good enough. Having to implement another
matching algorithm on the application level is a performance
problem. Consideration implementation difficulty, performance and
the user experience, I think passing the list of font alternatives
to the system Unicode imaging service and letting the system apply
its fallback algorithm would be quite sufficient when the system
offers font list-based fallback functionality. Also, considering
user experience, allowing (but not requiring) the user agent to
make decisions based on the content of the entire page is likely
to be better than doing per character font selection.
CSS WG response:
No change.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61869.450902.612360@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
14.3 Gamma correction
" Mac using QuickDraw
apply gamma 1.45 [ICC32] "
I think assuming a particular gamma based on platform is harmful.
The display gamma is configurable on the Mac. When the user agent
and doesn't really know the display gamma, I think it would be
better not to try to "correct" it. Applying "corrections" based on
guesses has been harmful in connection to the PNG format. See
http://iki.fi/hsivonen/png-gamma.html
"(ColorSync-savvy applications may simply pass the sRGB ICC
profile to ColorSync to perform correct color correction)"
The ICC rendering intent is not specified. If a PNG image where is
marked to be in the sRGB color space, which rendering intent
should be specified in order to match CSS colors in a User Agent
that does color matching based on ICC profiles?
CSS WG response:
Made the text informative instead of normative.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61280.674857.670826@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
2) Section 4.4 on CSS document representation
Mention should be made of the Unicode BOM and its relationship to
the encoding of the file.
Is BOM allowed?
The @charset rule is required to be the first character of the file.
For some people, it is confusing whether the BOM is considered a
character. (To me it is clear that it is not.)
Reply: http://www.w3.org/mid/20031015223936.GB5773@darby.dbaron.org
Response: http://www.w3.org/mid/3F8DDC83.8FE77A0B@i18nguy.com
CSS WG response:
[This is a response to the response to issue 44 as well.]
The new text reads:
When a style sheet resides in a separate file, user agents must
observe the following priorities when determining a style
sheet's character encoding (from highest priority to lowest):
1. An HTTP "charset" parameter in a "Content-Type" field
2. The @charset at-rule
3. BOM
4. <link charset=""> or other metadata from the linking
mechanism (if any)
5. charset of referring document (if any)
6. UA-dependent mechanisms
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: staffan.mahlen@comhem.se
Date: 2004-02-12
Archive: http://www.w3.org/mid/402BF500.18663.81B2B2@localhost
On 11 Feb 2004 at 21:40, Bert Bos wrote:
> ...The top of the
> aligned subtree is the highest of the tops of the boxes in the
> subtree, and the bottom is analogous.
> Changed definitions:
>
> 'top'
> Align the top of the aligned subtree with the top of the
line
> box.
> 'bottom'
> Align the bottom of the aligned subtree with the bottom of
the
> line box.
>
Interesting. The top of a box in the subtree in the last sentence of
the paragraph would be the top content edge i assume? I think it
might be wierd if margin/padding/border had the "expected" effect for
children of top or bottom aligned boxes but not (normally) otherwise.
To my mind this is an improvement and it does sound very reasonable
for CSS 2.1. However, personally i think that it might be wise to
consider an alternate model for inline rendering in a future version
of CSS. I would like to know if something like the following might
actually work without giving to many "backwards compatbility" issues,
or if another model could be constructed without causing to many
issues.
In case this is interesting to discuss, the rest of this message are
some more or less wild thoughts on such a model:
Each inline node (replaced as well as non-replaced) has a baseline.
The baseline of a replaced element is document language and/or UA
defined, while the baseline of a non-replaced element is defined by
its children as well as its text contents. Typically, a replaced
element such as an image would have a baseline below its bottom
margin edge, while any non-replaced elements or line box containing
text would have a baseline through its content area.
The baseline of a non-replaced inline box is defined by finding the
highest top margin edge of a child box or textnode, as well as the
lowest bottom margin edge, when the children are aligned vertically
in the box. The sum of those values is the box height.
Each box generated by an inline element is aligned versus its parent,
or if no parent exists, versus the line box. The top and bottom
values for the 'vertical-align' property are not relative to the line
box for an element that has a parent.
When calculation the edges, child boxes that have baseline as their
computed vertical-align are considered first. In the second pass when
children with vertical-align other than baseline are considered,
document order is used to set their position and caculate their
effect on the parent or line box. If for example a box holds two
images with the same distances from top margin edge to bottom margin
edge, their order becomes significant in calculating the baseline of
the box if their vertical-align differ.
I think something similar to the above might give a simpler model for
what goes where in inline rendering, if corrected and written up in
rec-talk. The idea is to vertical-align everything versus the parent,
and to let the non-replaced inlines get their height by their
contents, similar to blocks. In addition, i think allowing vertical
margin/padding/borders to "work" in an inline context would
be a good idea.
I have also been thinking about whether introducing a 'line-spacing'
property might reduce the issues with 'line-height'. This new
property would have the suggested default value of 0 to .2em, while
'line-height' would have the initial value 'auto'.
I've also been considering whether it would be feasible to allow
width/height for non-replaced inline elements, for instance by making
them apply to every box that element generates, but that might
introduce some interesting issues with horizontal positioning on the
line and how to scale the baseline as well as overflow considerations
i suppose.
One obvious difference in many pages seem to be (assuming an image
higher than 1.2em)
<a href="dummy" style="border: solid"><img src="dummy.png"/></a>
where the a-box would in this model be high enough to potentially be
the thing you click on when activating the link as you press the
image. This seems like a good thing to me.
Another example that would seem to work better in a model like the
above is of course
Text row one</br>
<span style="border-top: solid .5em">Text row two</span>
but that is for obvious reasons never used.
/Staffan
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61946.590634.80356@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F936BA4.123A233C@i18nguy.com
@font-face
CSS WG response:
Not enough implementations. The introduction now explicitly
mentions this as a criterium for CSS 2.1
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61557.33889.765202@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F8E49FF.A8ABAA98@i18nguy.com
For the purposes of matching, I wonder if it makes sense to
reference the RFCs at all. Isn't it really string matching based
on strings formatted with hyphen separators? Does any software
verify that the language tag contains appropriately registered
codes or uses ISO codes? Should it be an error, or perhaps the
rule ignored, if a CSS document specifies :lang(k9) since k9 is
not an offical language code or a properly formatted private code.
Some other messages on that thread (it's a long thread):
http://www.w3.org/mid/16270.39061.194849.106208@lanalana.inria.fr (bert)
http://www.w3.org/mid/15411558279.20031016161109@w3.org (chris)
http://www.w3.org/mid/Pine.GSO.4.58.0310162227430.238@korppi.cs.tut.fi
http://www.w3.org/mid/18316510540.20031016232304@w3.org (chris)
http://www.w3.org/mid/3F8F30C3.1F802EB6@i18nguy.com
http://www.w3.org/mid/4.2.0.58.J.20031016212319.06011f40@localhost
http://www.w3.org/mid/3F8F5666.DFB8DE6E@i18nguy.com (useful points)
http://www.w3.org/mid/3F8F59A9.5F0B455C@i18nguy.com
http://www.w3.org/mid/3F8F6723.B4BA94C5@i18nguy.com
http://www.w3.org/mid/Pine.GSO.4.58.0310171106140.15855@korppi.cs.tut.fi
http://www.w3.org/mid/16271.47379.949013.187179@lanalana.inria.fr (proposal)
http://www.w3.org/mid/3F8FC99A.12AEC995@i18nguy.com
http://www.w3.org/mid/115226064.20031017155409@w3.org
http://www.w3.org/mid/4.2.0.58.J.20031017140847.07153d28@localhost (proposal edits)
[...]
CSS WG response:
Here is the new text:
The pseudo-class ':lang(C)' matches if the element is in
language C. Whether there is a match is based solely on the
identifier C being either equal to, or a hyphen-separated
substring of, the element's language value, in the same way as
if performed by the '|=' operator. The identifier C doesn't have
to be a valid language name.
Exception: C may be empty, but it is undefined in CSS 2.1 what
it matches in that case. (This is likely to be defined in CSS
level 3.)
Note: It is recommended, that documents and protocols indicate
language using codes from RFC 3066 [RFC3066] or its successor,
and by means of "xml:lang" attributes in the case of XML-based
documents [XML10]. See "FAQ: Two-letter or three-letter
language codes."
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61833.837271.481366@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
13 Paged media
"The computed value of box margins at the top or bottom of the
page area is zero." Is there a reason why same rule doesn't apply
to left and right margins that touch the edges of the page area?
CSS WG response:
No change. The answer to the question is roughly the same as for
why margins collapse vertically and not horizontally.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61469.930908.25767@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
Also I assume that \a and \A are equivalent. True?
CSS WG response:
Yes.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61260.577978.622980@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0029.html
http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0030.html
Make HTML4 sample default stylesheet comprehensive
CSS WG response:
Added "html { display: block; }" but add nothing else (in
particular, not added anything that may be UA-dependent).
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61796.72333.974733@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
10.1 Definition of "containing block"
The example uses a HTML 4.0 Transitional doctype without a SYSTEM
id. The implementation practice (and CSS 2.1 is about
implementation practice) is not to treat such documents as
specified in this section. It would probably be clearer to use an
HTML 4.01 Strict doctype with a SYSTEM id.
CSS WG response:
Now uses HTML 4.01 strict.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-12
Archive: http://www.w3.org/mid/402BF173.1040003@mit.edu
Bert Bos wrote: > [This is a response to the response to issue 44 as well.] > The new text reads: Great! I have one tiny little nit... > 5. charset of referring document (if any) The referring thing could also be a stylesheet, of course (@import rules), in which case I would think this should be the charset of that stylesheet. -Boris
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61171.77156.911866@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F879634.2070002@escape.com
:first-letter
S5.12.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-letter>
# Some languages may have specific rules about how to treat certain
# letter combinations. In Dutch, for example, if the letter
# combination "ij" appears at the beginning of a word, both letters
# should be considered within the :first-letter pseudo-element.
The UA requirents wrt such combinations should be, IMO, more clearly
expressed.
CSS WG response:
Rejected.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61137.179716.680629@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F879634.2070002@escape.com
:first-letter
S5.12.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-letter>
There's also this degenerate case to consider:
| "_", foo
CSS WG response:
Not defined in CSS 2.1
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61526.604998.374365@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F8E49FF.A8ABAA98@i18nguy.com
Does ':lang()' match elements that have language set to the empty
tag?
It might be thought to match all languages, since in the absence
of simple selectors, * is presumed, so it is conceivable that
absence of a tag might be equivalent to all. It might also be
deemed to be an error to have no tag inside the parens.
So the spec should address the issue.
Reply: http://www.w3.org/mid/16270.39061.194849.106208@lanalana.inria.fr
CSS WG response:
:lang() is allowed, but undefined in CSS 2.1 (We'll define in
CSS3)
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61245.156261.190240@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/20031011130232.GA3710@tapir
Interaction of run-in with anonymous block boxes.
CSS WG response:
New text:
A run-in box behaves as follows:
1. If the run-in box contains a block box, the run-in box becomes
a block box.
2. If a sibling block box (that does not float and is not
absolutely positioned) follows the run-in box, the run-in box
becomes the first inline box of the block box. A run-in
cannot run in to a block that already starts with a run-in or
that itself is a run-in.
3. Otherwise, the run-in box becomes a block box.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61186.982900.183300@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F879634.2070002@escape.com
:first-letter and :before/:after (see end of e-mail)
Continued in: http://www.w3.org/mid/3F8DF3CC.4090308@escape.com
CSS WG response:
Added text:
If an element is a list item ('display: list-item'), the
':first-letter' applies to the first letter in the principal box
after the marker. UAs may ignore ':first-letter' on list items
with 'list-style-position: inside'. If an element has ':before'
or ':after' content, the ':first-letter applies to the first
letter of the element including that content.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61588.178851.675753@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F8E6343.710045EE@i18nguy.com
# ...consider the value of 'text-transform' to be 'none' for
# characters that are not from the Latin-1 repertoire and for elements
# in languages for which the transformation is different from that
# specified by the case-conversion tables of ISO 10646 ([ISO10646]).
a) I suspect you mean EITHER/OR not AND. ie the value can be none
if characters are EITHER not from Latin-1 OR for elements...
For example the letter i uses different conversion values in
Turkey, and I assume that even though it is a latin-1 letter, you
intended for the conversion to not be required.
I guess if the AND is intentional, you are saying that it is
better to do no case conversion than do the wrong conversion.
However, this seems silly, since then implementors need to have a
list of characters that have different conversions for certain
languages and insure that no conversion is performed. At the point
you are detecting these characters and language contexts, you may
as well implement the correct conversion.
CSS WG response:
Replace "for characters that are not from the Latin-1 repertoire
and for elements in languages for which the transformation is
different from that specified by the case-conversion tables of ISO
10646 ([ISO10646])." with "for writing scripts for which there is
no transform".
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61960.635700.764090@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9432F6.9080408@escape.com
S7.2.1 Media groups
http://www.w3.org/TR/2003/WD-CSS21-20030915/media.html#media-groups
# This section is informative, not normative.
^^^^^^^^^^^^^^^^^^^^^^^^^^
# Each CSS property definition specifies the media types for which the
# property must be implemented by a conforming user agent.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
????
CSS WG response:
Removed the conformance requirements.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61215.861025.252175@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F87E607.9030501@escape.com
Colors and Backgrounds
S14.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/colors.html#q2>:
# The background of the root element becomes the background of the
# canvas and covers the entire canvas, anchored at the same point
# as it would be if it was painted only for the root element itself.
# The root element does not paint this background again.
It is unclear what is meant by this.
CSS WG response:
What's unclear?
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61229.958900.252878@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F87E607.9030501@escape.com
Colors and Backgrounds
S14.2.1<http://www.w3.org/TR/2003/WD-CSS21-20030915/colors.html#background-properties>:
# The tiling and positioning of the background-image on inline elements
# is undefined in this specification. A future level of CSS may define
# the tiling and positioning of the background-image on inline elements.
Must CSS2.1 really make the tiling and positioning of all inline
elements undefined or can it get away with leaving backgrounds on
*multi-line* inline elements undefined?
CSS WG response:
Leaving undefined for now, see CSS3.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61896.710632.410220@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F930BAC.3EBE051D@i18nguy.com
http://www.w3.org/TR/CSS21/visuren.html#direction
proposal to change bidi requirement
Followup: http://www.w3.org/mid/3F930E44.8813BEC1@i18nguy.com
CSS WG response:
Used the text as in the last message mentioned above.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61742.161095.294103@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
5.9 ID selectors
Unlike class selectors, the id selectors are defined to depend on
the IDness defined in the DTD. For performance reasons, Web
browser can reasonably be expected not to process the external DTD
subset. Therefore, id selectors when used with XHTML would fail in
most if not all Web browsers. I suggest allowing the UA to have
hard-coded knowledge about IDness based on the namespace--just
like the UA is expected to have hard-coded knowledge about what
constitutes class.
CSS WG response:
Yes, note added.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61931.909311.355830@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F93547A.1F7C7C1C@i18nguy.com
References that need updating.
CSS WG response:
Updated
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61379.908812.394931@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
I am surprised that the on section URIs doesn't mention IRIs.
CSS WG response:
A CR can't reference anything before a last call, and IRIs
aren't last call.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61998.590572.291438@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
S6.1.2: Computed values
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#computed-value
# For absolute values, no computation is needed to find the computed value.
Is the computed value of "1cm" and "10mm" the same or different?
Because you need to convert in order to make them the same, and
converting units involves computation...
CSS WG response:
We appreciate your input but we don't really want to change this
at this time.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61511.332061.654384@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F8E49FF.A8ABAA98@i18nguy.com
Section 5.11.4 on :lang still references RFC 1766.
Although HTML technically refers to 1766, XML has been upgraded to
RFC 3066 for its support of 3 letter tags and also prescribes the
empty tag to allow the removal of language info. And most browsers
I believe do support rfc 3066 for html anyway.
CSS should therefore address rfc 3066
CSS WG response:
Changed.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61572.906764.676666@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F8E6343.710045EE@i18nguy.com
What should copying to the clipboard copy?
CSS WG response:
UA defined.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61199.267854.605641@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F87E24C.10509@escape.com
Overflow and backgrounds. (Detailed argument.)
CSS WG response:
We have interoperability now.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61352.349177.974034@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
More generally, I find the character numbering a little confusing.
It is in fact self-consistent, but it is not obvious to the reader
without some checking and if you don't recognize the values.
CSS WG response:
Octal kept for Lex code, U+hhhh everywhere else.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61317.429022.962180@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
Where does BOM fit in the precedence hierarchy?
CSS WG response:
see issues 115 & 44.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-12
Archive: http://www.w3.org/mid/16427.61660.135545.111584@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9221BA.B938248A@i18nguy.com
The Long description illustrating relationship between page box
and sheet
http://www.w3.org/TR/CSS21/images/longdesc/page-info-desc.html has
a link "return to image" which is incorrect. Should return to the
section on page margins 13.2.1, but instead goes back to section
12.
CSS WG response:
Corrected.
For the CSS WG,
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdoxp030416@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
S9.5.2 Controlling flow next to floats: the 'clear' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#flow-control
# The clearance dimension is introduced as a dimension above the
# margin-top of an element that is used to push the element
# vertically (typically downward).
Calling it a dimension doesn't seem quite right. How about:
Clearance is introduced as spacing above the margin-top of an
element. It is used to push the element vertically downward,
past the float.
CSS WG response:
Changed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdoRG030420@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
# Values have the following meanings when applied to non-floating
# block boxes:
What about floating boxes?
CSS WG response:
It's mentioned a few paragraphs lower down.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdqKq030500@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ECB2.3080503@escape.com
# See the sections on the width and height of absolutely
# positioned, non-replaced elements for details
Strike out "non-replaced".
CSS WG response:
We disagree.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdqVe030544@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED7C.8070206@escape.com
S8.6 The box model for inline elements in bidi context
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#q11
Beautiful! I would make one change, however:
# the left-most generated box of the first line box in which the
# element appears has a left margin, left border and left padding
^
Change "a left margin" to "the left margin", and likewise for the
other three analogous instances.
CSS WG response:
Changed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdrQ8030564@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200310270540.h9R5ehJv016652@nerd-xing.mit.edu
-- Section 9.1.2 (Containing blocks)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#containing-block>
Does the root element sentence really belong here rather than in
the sections describing those properties?
CSS WG response:
Changed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdp8U030464@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ECB2.3080503@escape.com
# Properties set on elements that are turned into anonymous block boxes
# still apply to the content of the element. For example, if a border
# had been set on the BODY element in the above example, the border
# would be drawn around C1 and C2.
Would the border be drawn as a block border around C1 and another
around C2, or would the border be drawn as an inline border around
C1 and another around C2?
CSS WG response:
See issue 206.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdqea030512@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED7C.8070206@escape.com
S8.2 Examples of margins, padding, and borders
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#mpb-examples
# The content width for each LI box is calculated top-down; the
# containing block for each LI box is established by the UL
# element.
The relationship between these two sentences is not clear. What
does top-down calculation have to do with the UL establishing a
containing block for each LI?
CSS WG response:
The spec seems clear to us. (It's basically saying the same thing
in two different ways: the widths are determined from the root
element down to the inner most elements, via the containing block
hierarchy.)
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdq6E030520@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED7C.8070206@escape.com
S8.3 Margin properties
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#margin-properties
# If the containing block's width depends on this element, then
# the resulting layout is undefined in CSS 2.1.
Might want to give an example of when this happens.
CSS WG response:
Not in CSS 2.1. (We might define it later. Could even require
solving a system of equations. But not now.)
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdoSq030396@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
# Example. In the following document fragment, the containing
# block is too short to contain the content
Too narrow, not too short. The /line boxes/ are too short next to
the float; the containing block is wide (and long) enough.
CSS WG response:
Changed
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdqp0030540@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED7C.8070206@escape.com
S8.5.3
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#border-style-properties
# none
# No border.
I'd put
> No border; the border width is zero.
CSS WG response:
Changed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdrVJ030552@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94F0D9.7060200@escape.com
# In this process, non-textual entities such as images are treated
# as neutral characters
as object replacement characters (U+FFFC)
CSS WG response:
We don't see why this is useful.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdsDk030612@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
# Note: The specificity is based only on the form of the selector.
# In particular, a selector of the form "[id=p33]" is counted as an
# attribute selector (a=0, b=0, c=1, d=0), even if the id attribute
# is defined as an "ID" in the source document's DTD.
This text should be normative, not informative, and therefore
should not be marked as a note. Also, move it up to before "Some
examples", right after "Contcatenating the four numbers a-b-c-d
(in a number system with a large base) gives the specificity".
CSS WG response:
editorial, editor to deal with this
*Bert* Further communication is required.
*howcome* Document to be updated.
---
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdpf1030440@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
(And wouldn't it be better to use a proper em-dash?)
CSS WG response:
No change.
For the CSS WG,
Bert
From: fantasai (fantasai@escape.com)
Date: 2004-02-13
Archive: http://www.w3.org/mid/402D2D44.8030707@escape.com
Bert Bos wrote: > This is the CSS WG's response to an issue you raised on the last CSS > 2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to > publish CSS 2.1 as a CR in about two weeks. Please let us know this > week if you think our response is wrong. > > Your e-mail: > http://www.w3.org/mid/3F94ECB2.3080503@escape.com > > # See the sections on the width and height of absolutely > # positioned, non-replaced elements for details > > Strike out "non-replaced". > > CSS WG response: > We disagree. I don't see why. The sections on the width and height of absolutely positioned, replaced elements offer details on the interpretation of 'auto' as well. ~fantasai
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdngt030356@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
# Rules specified in a given style sheet override rules of the same
# weight imported from other style sheets.
Even if the imported rules have higher specificity? I think you
mean to say that rules in an imported style sheet are considered
to be before the rules in the importing stylesheet.
CSS WG response:
Change "weight (...) and origin (...)" in 6.4.1 to "importance
(...) and origin (...)"
Strike the quoted paragraph in 6.4 beginning with "Rules specified"
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdrqF030576@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200310270540.h9R5ehJv016652@nerd-xing.mit.edu
-- Section 9.2.2 (Inline-level elements and inline boxes)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q7>
'inline-block' should be listed as a display type that makes an
element inline.
(I disagree; the spec is written in such a way that inline-block is
neither inline-level nor block-level, but listed explicitly where
appropriate. - ian)
CSS WG response:
Disagree. Inline-block is not included in inline-level or
block-level, but mentioned explicitly wherever needed.
For the CSS WG,
Bert
From: Tantek Çelik (tantek@cs.stanford.edu)
Date: 2004-02-13
Archive: http://www.w3.org/mid/BC5270B3.3640F%25tantek@cs.stanford.edu
On 2/13/04 11:42 AM, "fantasai" <fantasai@escape.com> wrote: > > Bert Bos wrote: > >> This is the CSS WG's response to an issue you raised on the last CSS >> 2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to >> publish CSS 2.1 as a CR in about two weeks. Please let us know this >> week if you think our response is wrong. >> >> Your e-mail: >> http://www.w3.org/mid/3F94ED06.5060006@escape.com >> >> # Stacking contexts are not necessarily related to containing blocks. >> # In future levels of CSS, other properties may introduce stacking >> # contexts, for example 'opacity'. >> >> The second sentence should not have [an example]. >> >> CSS WG response: >> No change. We disagree. > > The reason I say you should not have an example is because > referring to a CSS3 property in a CSS2 specification creates > unnecessary dependencies between the two and should thus > generally be avoided. First, no dependency has been created because the remark is informative due to the use of the phrase "for example". Second, there is value to be gained by offering readers relevant cross-references. Because cross-references are valuable, they should generally not be avoided. Third, CSS3 Color (where 'opacity' is defined) is a Candidate Recommendation, and certainly there is no problem with one CR referencing another. Tantek
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdnCm030368@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
S6.4.3: Calculating a selector's specificity
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#specificity
# Concatenating the four numbers a-b-c-d (in a number system with
# a large base) gives the specificity.
Use of dashes here doesn't match use of commas in the examples.
CSS WG response:
Changed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdrGJ030548@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94F0D9.7060200@escape.com
> S9.10 Text direction: the 'direction' and 'unicode-bidi' properties
> http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#direction
Left out the rest:
# For block-level elements this creates an override for
# inline-level descendents not within another block.
Why does adding a "display: block" to an element in a paragraph
all of a sudden obviate the need for a directional override?
CSS WG response:
See CSS3 Text or a tutorial for details about why
'direction' and 'unicode-bidi' work this way. No change in CSS 2.1
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdodR030384@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
S9.4.3 Relative positioning
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#relative-positioning
# Relative positioning may also be used as a general form of
# superscripting and subscripting except that line height is not
# automatically adjusted to take the positioning into
# consideration.
change to
Although relative positioning may be used as a form of superscripting and
subscripting, the line height is not automatically adjusted to take the
positioning into consideration.
CSS WG response:
Changed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdp4U030488@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ECB2.3080503@escape.com
S9.2.4 The 'display' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#display-prop
# and the element itself is formatted as a replaced element on the line.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
change to
as an inline replaced element.
CSS WG response:
Changed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdr3I030556@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F96E580.26593.6A6B1A@localhost
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats
# The margin box of an element in the normal flow that establishes a
# new block formatting context (such as a table, or ...
That 'table' should possibly read table-cell, but i think it makes
more sense to update
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q15
to include tables as well.
CSS WG response:
Updated to
"The margin box of a table or an element in the normal flow that
establishes a new block formatting context (such as an element
with 'overflow' other than 'visible') must not overlap any
floats in the same block formatting context as the element
itself."
(Note that a display:table does not establish a block formatting
context, a display:table establishes a table formatting
context.)
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdojX030436@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
S9.8.4 Absolute positioning
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q28
# Relative and absolute positioning may be used to implement change
# bars, as shown in the following example.
# ... the change bars seem to "float" to the left of the current line.
Wouldn't it make more sense to use a float?
CSS WG response:
No change.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdpVc030484@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ECB2.3080503@escape.com
Also, see
http://lists.w3.org/Archives/Public/www-style/2000May/0010.html
CSS WG response:
Covered by issue 103, we believe.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdn4v030360@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
6.4.2 !important rules
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#important-rules
# the keywords "!" and "important" follow the declaration
Since when is "!" a keyword?
CSS WG response:
Yep, it's a delim token. Updated.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdpJJ030460@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ECB2.3080503@escape.com
S9.2.1 Block-level elements and block boxes: Anonymous block boxes
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#anonymous-block-level
# The properties of anonymous boxes are inherited from the
# enclosing non-anonymous box (in the example: the one for DIV).
There's no DIV in the example. (It would make sense for the
example a few paragraphs up, but that's not in range of this
sentence.)
CSS WG response:
Added after "the example": `just below the subsection heading
"Anonymous block boxes"'
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdnw7030348@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
6.3 The @import rule
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#at-import
Move this section to either before Specified, Computed and Actual
Values or after The Cascade, because it breaks up the conceptual
flow between these two sections.
CSS WG response:
We appreciate your input but we don't really want to
change this at this time.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdnNS030380@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
# The following user stylesheet would override the font weight of
# 'b' elements in all documents, and the color of 'font' elements
# with color attributes...
I personally think an example with <center> and <div
align="center"> would be more interesting... =]
CSS WG response:
No comment...
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdrC6030572@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200310270540.h9R5ehJv016652@nerd-xing.mit.edu
The part about being turned into anonymous block boxes that
follows the example is also confusing.... What does it mean for
the border of the BODY to apply in this case? The spec sounds like
it should draw two block-like borders -- one around the anonymous
block containing C1, one around the anonymous block containing C2.
CSS WG response:
Replace the last paragraph of 9.2.1 with:
Properties set on elements that cause anonymous block boxes to
be generated still apply to the boxes and content of that
element. For example, if a border had been set on the BODY
element in the above example, the border would be drawn around
C1 (open at the end of the line) and C2 (open at the start of
the line).
Some user agents have implemented borders on inlines containing
blocks in other ways, e.g. by wrapping such nested blocks inside
"anonymous line boxes" and thus drawing inline borders around
such boxes. As CSS1 and CSS2 did not define this behavior,
CSS1-only and CSS2-only user agents may implement this
alternative model and still claim conformance to this part of
CSS2.1. This does not apply to UAs developed after this
specification was released.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdo3C030424@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
# Example:
#
# span { clear: left }
This example is useless. Take it out.
CSS WG response:
Removed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdoaq030388@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
S9.5 Floats
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats
# The top of the floated box is aligned with the top of the
# current line box (or bottom of the preceding block box if no
# line box exists).
Are you saying that a float floats over it's parent's top
margin+border+padding?
CSS WG response:
Replaced with:
If there's a line box, the top of the floated box is aligned
with the top of the current line box.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdoBc030404@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
S9.5.1 Positioning the float: the 'float' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#float-position
# It may be set for elements that generate boxes that are not
# absolutely positioned.
It can be set for any element. It just doesn't _apply_ to some of
them.
CSS WG response:
New text:
It may be set for any element, but only applies to elements that
generate boxes that are not absolutely positioned.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdp8v030472@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ECB2.3080503@escape.com
If it's a block border, then what happens with:
<p>There's an <em>interesting <span class="block">formatting</span>
effect</em> in this paragraph.</p>
em { border: solid }
.block { display: block }
?
CSS WG response:
It's not a block border.
For the CSS WG,
Bert
From: fantasai (fantasai@escape.com)
Date: 2004-02-13
Archive: http://www.w3.org/mid/402D2E5E.9010505@escape.com
Bert Bos wrote: > This is the CSS WG's response to an issue you raised on the last CSS > 2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to > publish CSS 2.1 as a CR in about two weeks. Please let us know this > week if you think our response is wrong. > > Your e-mail: > http://www.w3.org/mid/3F94ED7C.8070206@escape.com > > S8.3.1 Collapsing margins > http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#collapsing-margins > > The number of times "clearance" is referred to without reasonable > context or previous definition is just maddening. Call it "float > clearance" or something, at least. > > (I've been reading straight through, so continuity problems are > more evident.) > > CSS WG response: > The hyperlink is good enough. We don't know how to resolve > this otherwise. > We don't know how to resolve this otherwise. s/clearance/float clearance/ ~fantasai
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdpKX030468@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ECB2.3080503@escape.com
Would the border split where the block occurs? I.e. if it's a
block border, would the bottom border not exist for C1/if it's an
inline border, would the last border not exist for C1?
CSS WG response:
It's inline, and the last border does indeed not exist for
C1, but the spec is clear about this in our opinion.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdnZC030364@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
# The first rule in the user's style sheet in the following example...
I think the example would be more illustrative if the second rules
in the author and user style sheets were switched.
CSS WG response:
Maybe, but not very important.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdpem030492@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ECB2.3080503@escape.com
S9.3.1 Choosing a positioning scheme: 'position' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#choose-position
> In the case of the print media type, the box is fixed with respect to
> the page
If it repeats on every page, then that should be mentioned here.
CSS WG response:
Added.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdqHx030516@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED7C.8070206@escape.com
# The right padding of the LI boxes has been set to zero width
# (the 'padding' property). The effect is apparent in the second
# illustration. ^^^^^^^^^^^^^^^^^^
No it's not.
CSS WG response:
Image improved. Also added that image is not to scale.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdpcK030444@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
S9.9.1 Specifying the stack level: the 'z-index' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#z-index
# In this section, the expression "in front of" means closer to the
# user as the user faces the screen.
screen -> canvas
CSS WG response:
No change.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdnQl030352@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
6.4 The Cascade
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#cascade
# Note that the default style sheet may change if system settings
# are modified by the user (e.g., system colors). However, due to
# limitations in a user agent's internal implementation, it may be
# impossible to change the values in the default style sheet.
This note seems rather useless. If there's no good justification
for putting it in, then take it out.
CSS WG response:
Changed to informative note: "Note that the user may modify system
settings (e.g. system colors) that affect the default style sheet.
However, some user agent implementations make it impossible to
change the values in the default style sheet."
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdp17030452@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
# Stacking contexts are not necessarily related to containing blocks.
# In future levels of CSS, other properties may introduce stacking
# contexts, for example 'opacity'.
The second sentence should not have [an example].
CSS WG response:
No change. We disagree.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdo9Q030400@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
# Formatting would have been exactly the same if the document had been:
...
# because the content to the left of the float is displaced by the float
# and reflowed down its right side.
Poor explanation, imo. Try:
because the float is taken out of the flow from the same line as in
the previous example.
CSS WG response:
Disagree, original is better.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdoXe030412@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
# References to other elements in these rules refer only to other
# elements in the same block formatting context as the float..
But weren't you just talking about inline elements? (Like in rule
5.) Inlines don't participate in the block formatting context.
CSS WG response:
Yes, they do, so we reject the change.
Removed two periods at the end of the sentence.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdp1u030480@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ECB2.3080503@escape.com
S9.2.3: Run-in boxes
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#run-in
# If a block box (that does not float and is not absolutely
# positioned) follows the run-in box, the run-in box becomes the
# first inline box of the block box.
I don't think the intention is to have last-child run-ins combine
with their parents' next-siblings, so change that to "a sibling
block box".
CSS WG response:
Changed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdqfT030524@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED7C.8070206@escape.com
# margin-top, margin-bottom
# Applies to: all elements but inline, non-replaced elements and
# internal table elements
Any reason why it doesn't need to apply to inline, non-replaced
elements? Borders and padding do; they just don't have an effect
on line-height calculation. Since that seems to be the rationale
for excluding it, I'd just combine the definitions for all margins
and leave the no-effect part to the inline model explanation.
CSS WG response:
Little difference between doesn't apply and no effect. But new
text reads:
Applies to: all elements except elements with table display
types other than table and inline-table
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdoKx030428@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
9.8.3 Floating a box
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q27
The image for these examples imply that all the leading is added
on top of the line. They should depict a 50/50 split in the
leading.
CSS WG response:
Images not changed, but text added to section 9.8:
"Note. The diagrams in this section are illustrative and not to
scale. They are meant to highlight the differences between the
various positioning schemes in CSS 2.1, and are not intended to
be reference renderings of the examples given."
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdrIU030560@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F96E580.26593.6A6B1A@localhost
Also, i think it may be a good idea to change the heading
"9.4.1 Block formatting context"
to
"9.4.1 Block formatting contexts"
to make it more explicit that there are multiple.
CSS WG response:
Changed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdnkk030372@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
Secondly, the 'spacing' attribute of <orderedlist> in DocBook
<http://www.docbook.org/tdg/en/html/orderedlist.html> is clearly
presentational. Trying to deny this is silly. What you /want/ to
do is to restrict the special handling of presentational hints to
HTML.
Like this:
# The UA may choose to honor presentational attributes in the source
# document.
> The UA may choose to honor presentational attributes in an HTML
> source document.
CSS WG response:
Changed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdpWd030456@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
# The default behavior of a box is to allow boxes behind it to be
# visible through transparent areas in its content.
The default behavior of the background is...
CSS WG response:
Changed.
For the CSS WG,
Bert
From: fantasai (fantasai@escape.com)
Date: 2004-02-13
Archive: http://www.w3.org/mid/402D2EA0.3090309@escape.com
Bert Bos wrote: > This is the CSS WG's response to an issue you raised on the last CSS > 2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to > publish CSS 2.1 as a CR in about two weeks. Please let us know this > week if you think our response is wrong. > > Your e-mail: > http://www.w3.org/mid/3F94F0D9.7060200@escape.com > # In this process, non-textual entities such as images are treated > # as neutral characters > > as object replacement characters (U+FFFC) > > CSS WG response: > We don't see why this is useful. It gives a more precise link to the desired behavior in bidi reordering. ~fantasai
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdovt030392@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
# The margin box of an element in the normal flow that establishes
# a new block formatting context (such as a table, or element with
# 'overflow' other than 'visible') must not overlap any floats in
# the same block formatting context as the element itself. If
# necessary, implementations should clear the said element by
# placing it below any preceding floats, but may place it adjacent
# to such floats if there is sufficient space.
The margin box of an element in normal flow is always as wide as
the containing block. What is this rule *supposed* to say?
CSS WG response:
We think it's good enough. Not made any more precise for CSS 2.1.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdqhv030528@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED7C.8070206@escape.com
S8.3.1 Collapsing margins
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#collapsing-margins
The number of times "clearance" is referred to without reasonable
context or previous definition is just maddening. Call it "float
clearance" or something, at least.
(I've been reading straight through, so continuity problems are
more evident.)
CSS WG response:
The hyperlink is good enough. We don't know how to resolve
this otherwise.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdqKX030504@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ECB2.3080503@escape.com
S9.4.1 Block formatting context
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q15
# In a block formatting context, each box's left outer edge touches the
# left edge of the containing block (for right-to-left formatting, right
# edges touch). This is true even in the presence of floats (although a
# box's line boxes may shrink due to the floats).
What about clearance?
CSS WG response:
Clearance doesn't affect it (wrong axis) -- See also issue 60b.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdp3n030476@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ECB2.3080503@escape.com
S9.2.2 Inline-level elements and inline boxes: Anonymous inline boxes
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#anonymous
# The <p> generates a block box, with several inline boxes inside
# it... ...they don't have an associated inline-level element.
No mention of the conditions for creating an anonymous inline.
CSS WG response:
This will be better defined in CSS3.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdnIc030376@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
# For XHTML and other languages written in XML, no attribute
# should be considered presentational. The styling of elements and
# non-presentational attributes should be handled in the user
# agent stylesheet.
> For other languages, all document language-based styling should be
> handled in the user agent style sheet.
CSS WG response:
Changed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdnZO030344@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
# If the user agent does not have the 12pt font available...
Change 120% to 130% and make it 13pt font. Because the vast
majority of fonts out there do have 12pt versions--13pt is not a
common size and is therefore more likely not to exist.
CSS WG response:
yep
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHds8N030616@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F9408C5.2040507@escape.com
S6.4.4: Precedence of non-CSS presentational hints
# For XHTML and other languages written in XML, no attribute
# should be considered presentational. The styling of elements and
# non-presentational attributes should be handled in the user
# agent stylesheet.
First off, the non-presentational attributes aren't being styled.
The elements to which they belong are being styled based on these
attributes.
CSS WG response:
Seems rather minor. We'll probably leave it as is.
For the CSS WG,
Bert
From: fantasai (fantasai@escape.com)
Date: 2004-02-13
Archive: http://www.w3.org/mid/402D28C3.3010406@escape.com
Bert Bos wrote: > This is the CSS WG's response to an issue you raised on the last CSS > 2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to > publish CSS 2.1 as a CR in about two weeks. Please let us know this > week if you think our response is wrong. > > Your e-mail: > http://www.w3.org/mid/3F94ED06.5060006@escape.com > > # Stacking contexts are not necessarily related to containing blocks. > # In future levels of CSS, other properties may introduce stacking > # contexts, for example 'opacity'. > > The second sentence should not have [an example]. > > CSS WG response: > No change. We disagree. The reason I say you should not have an example is because referring to a CSS3 property in a CSS2 specification creates unnecessary dependencies between the two and should thus generally be avoided. If you need to specify somewhere that CSS3's 'opacity' creates a stacking context, specify it in CSS3's 'opacity' description, not here. ~fantasai
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdqJk030508@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ECB2.3080503@escape.com
S9.10 Text direction: the 'direction' and 'unicode-bidi' properties
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#direction
# For the 'direction' property to have any effect on inline-level
# elements... ^^^^^^^^^^^^^^^^^^
change to
For the 'direction' property to affect reordering in inline-level
elements...
CSS WG response:
Changed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdrg9030568@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/200310270540.h9R5ehJv016652@nerd-xing.mit.edu
-- Section 9.2.1 (Anonymous block boxes)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#anonymous-block-level>
The example talks about having a "anonymous block box for BODY".
I'm not sure what this means. Since the BODY is an inline inside a
block (HTML), and the boxes of BODY end up with a block sibling
(the P), I would expect an anonymous block _around_ the BODY
boxes. But the boxes of BODY should be inline.
This example should probably be clarified.
CSS WG response:
"anonymous block box for BODY" changed to "anonymous block
box around the BODY".
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdoDp030432@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
# #sibling { clear: right; color: red }
I thought we just established that 'float' does not apply to
inline elements?
CSS WG response:
The example is indeed inaccurate, but we're going to leave
it for now.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdoWF030408@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
# Same as 'left', but content flows on the left side of the box,
# starting at the top.
No, it's not the same as 'left' because it's floated to the
_right_, not the left.
CSS WG response:
Fixed.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdqIu030532@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED7C.8070206@escape.com
# Vertical margins between a floated box and any other box do not
# collapse (not even between a float and its in-flow children).
Not even between two boxes both floating left? Things would look
nicer imo if these margins would collapse.
CSS WG response:
This is something interoperably implemented which originated in
CSS1.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdqZm030496@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ECB2.3080503@escape.com
S9.3.2 Box offsets: 'top', 'right', 'bottom', 'left'
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#choose-position
It seems like the property definitions for top, right, left, and
bottom could be combined into one table+description+note. Other
than the name of the side, the text is exactly the same.
# The offset is a percentage of the containing block's box width
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
change to
containing block's width
CSS WG response:
Dealt with by issue 62.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdqvG030536@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED7C.8070206@escape.com
S8.5 Border properties
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#border-properties
# Note. Notably for HTML, user agents may render borders for
# certain elements (e.g., buttons, menus, etc.) differently than
# for "ordinary" elements.
Are you sure you want this to be informative? Also, I suggest
adding "user interface" between 'certain' and 'elements'.
CSS WG response:
Kept it informative. "User interface" added.
For the CSS WG,
Bert
From: Bert Bos (bert@w3.org)
Date: 2004-02-13
Archive: http://www.w3.org/mid/200402131739.i1DHdpsZ030448@lanalana.inria.fr
This is the CSS WG's response to an issue you raised on the last CSS
2.1 draft (http://www.w3.org/TR/2003/WD-CSS21-20030915). We want to
publish CSS 2.1 as a CR in about two weeks. Please let us know this
week if you think our response is wrong.
Your e-mail:
http://www.w3.org/mid/3F94ED06.5060006@escape.com
# Stacking contexts are not necessarily related to containing
# blocks. In future levels of CSS, other properties may introduce
# stacking contexts, for example 'opacity'.
The first sentence needs an example.
CSS WG response:
No change. We disagree.
For the CSS WG,
Bert
From: David Woolley (david@djwhome.demon.co.uk)
Date: 2004-02-14
Archive: http://lists.w3.org/Archives/Public/www-style/2004Feb/0279.html
> # For XHTML and other languages written in XML, no attribute > # should be considered presentational. The styling of elements and I would say most attributes in SVG were presentational!
From: Bjoern Hoehrmann (derhoermi@gmx.net)
Date: 2004-02-16
Archive: http://lists.w3.org/Archives/Public/www-style/2004Feb/0315.html
* Tantek Çelik wrote:
>The working group has no obligation to report even the existence of
>responses/objections made after the last call review deadline.
>It is relevant in that the only objections the working group must respond to
>are those made before the last call deadline. New objections, even if they
>are made in the middle of some other thread, do not require a response.
>And the working group replied and explained away your objections, which is
>sufficient.
<http://www.w3.org/2004/02/Process-20040205/>:
[...]
3.3.2 Recording and Reporting Formal Objections
When individual registers a formal objection to a decision, the
individual SHOULD cite technical arguments and propose changes that
would remove the objection; these proposals MAY be vague or
incomplete. When an objection concerning a document on the
Recommendation Track or the Process Document includes such
information, the Chair MUST report it to the Director in the next
request to advance the document (e.g., in the request to the
Director to advance a technical report to Candidate Recommendation).
[...]
7.2 General Requirements for Advancement
For a Call for Implementations up to and including publication as a
Recommendation, the Working Group MUST:
[...]
6. Formally address all issues raised about the document since
the previous step.
[...]
7. Report any formal objections.
The following information is important to the decision to advance a
technical report and therefore MUST be publicly available:
[...]
* Responses that formally address issues raised by reviewers;
* Any formal objections.
[...]
7.3 Reviews and Review Responsibilities
A document receives review from the moment it is first published.
Starting with the First Public Working Draft until the start of a
Proposed Recommendation review, a Working Group MUST formally
address /any/ substantive review comment about a technical report
and SHOULD do so in a timely manner.
[...]
The Working Group MUST be able to show evidence of having attempted
to respond to and satisfy reviewers. Reviewers MAY register a formal
objection any time they are dissatisfied with how a Working Group has
handled an issue.
[...]
Ordinarily, reviewers SHOULD NOT raise substantive technical issues
about a technical report after the end of a Last Call review period.
However, this does occur, and as stated above, a Working Group's
requirement to formally address those issues extends until the end of
a Proposed Recommendation review period.
[...]
A reviewer MAY register a formal objection.
[...]
When a Working Group receives a substantive issue after the end of
Proposed Recommendation review period, the Working Group MUST respond
to the reviewer but MAY decline to formally address the issue.
[...]
7.4.3 Call for Implementations
[...]
Entrance criteria: The Director calls for implementation when
satisfied that the Working Group has fulfilled the general
requirements for advancement.
[...]
From: Bjoern Hoehrmann (derhoermi@gmx.net)
Date: 2004-02-16
Archive: http://www.w3.org/mid/405619dc.352823283@smtp.bjoern.hoehrmann.de
* Tantek Çelik wrote: >> I assume you mean by considering it closed that the Working Group will >> report my objection to the Director in their request for advancement. > >By considering it closed we mean that the points raised in your previous >emails in this thread have been responded to. Ok. >Please quote and cite with URL predating the CSS 2.1 LC deadline what you >consider your objection to be, because otherwise, the group believes all >your objections have been responded to and properly explained. I am just pointing out that your response does not remove my objection.
From: Tantek Çelik (tantek@cs.stanford.edu)
Date: 2004-02-16
Archive: http://www.w3.org/mid/BC5641E9.3673B%25tantek@cs.stanford.edu
On 2/11/04 6:40 AM, "Bjoern Hoehrmann" <derhoermi@gmx.net> wrote: > > * Ian Hickson wrote: >> On Tue, 10 Feb 2004, David Woolley wrote: >>> I might think that a lot of this sort of animation is bad for users, >>> but that is not the perception of the people with the money to pay >>> for sites, so any W3C specification that doesn't acknowledge it will >>> be treated as an irrelevance. >> >> Any W3C specification that "acknowledges" a feature by describing it in a >> way completely different to the real world will also be treated as an >> irrelevance. I don't see why you would prefer the spec to be wrong >> (effectively, to lie) than to simply not mention the features which are >> not interoperably implemented. > > That's not the point. The W3C Recommendation Track process is designed > to standardize Web technology by maximizing consensus about the content > of a technical report. If a feature does not get implemented at all, > spite the expectation of the Working Group, the feature should be > reconsidered and probably be revised rather than be dropped blindly. If > a feature is not interoperably implemented, the Working Group should do > further work to gain interoperability. That is precisely what the working group is doing. What you have described is the difference between CSS2.1 and the CSS3 modules. Features which have been interoperably implemented will be kept in CSS2.1. Otherwise, they will not be "dropped blindly". They will be moved to the appropriate CSS3 module(s), so the working group can do further work to gain interoperability. Thus your last comment in this thread is accepted. Any features "dropped" from CSS2.1 will be included in the appropriate CSS3 module(s), and they will not be dropped blindly. Thanks for your feedback. Tantek Çelik for the CSS WG
From: Tantek Çelik (tantek@cs.stanford.edu)
Date: 2004-02-16
Archive: http://www.w3.org/mid/BC5677AD.367B5%25tantek@cs.stanford.edu
On 2/16/04 1:04 PM, "Bjoern Hoehrmann" <derhoermi@gmx.net> wrote: > > * Tantek Çelik wrote: >>> I assume you mean by considering it closed that the Working Group will >>> report my objection to the Director in their request for advancement. >> >> By considering it closed we mean that the points raised in your previous >> emails in this thread have been responded to. > > Ok. > >> Please quote and cite with URL predating the CSS 2.1 LC deadline what you >> consider your objection to be, because otherwise, the group believes all >> your objections have been responded to and properly explained. > > I am just pointing out that your response does not remove my objection. I am just pointing out that by failing to provide a quote and cite with URL predating the CSS 2.1 LC deadline with what you consider your objection to be, you have removed your objection. Thanks, Tantek
From: Bjoern Hoehrmann (derhoermi@gmx.net)
Date: 2004-02-16
Archive: http://www.w3.org/mid/405b38e7.360770710@smtp.bjoern.hoehrmann.de
* Tantek Çelik wrote: >>>> I assume you mean by considering it closed that the Working Group will >>>> report my objection to the Director in their request for advancement. >>> >>> By considering it closed we mean that the points raised in your previous >>> emails in this thread have been responded to. >> >> Ok. >> >>> Please quote and cite with URL predating the CSS 2.1 LC deadline what you >>> consider your objection to be, because otherwise, the group believes all >>> your objections have been responded to and properly explained. >> >> I am just pointing out that your response does not remove my objection. > >I am just pointing out that by failing to provide a quote and cite with URL >predating the CSS 2.1 LC deadline with what you consider your objection to >be, you have removed your objection. I may register formal objection at *any time* and I obviously cannot register formal objection prior to the review deadline if I object to a response of the Working Group that is sent past this deadline, hence I do not understand how the Last Call Review Deadline is relevant here. I neither understand why I need to point you at my formal objection, http://lists.w3.org/Archives/Public/www-style/2004Feb/0102.html http://lists.w3.org/Archives/Public/www-style/2004Feb/0107.html I sent it to the list in response to what I object to, that should be absolutely sufficient. Since I cited technical arguments and proposed changes to remove my objection, the chair is required to report my objection to the Director as general rule of advancement. Please cite the relevant sections in the Process Document if you disagree.
From: Ian Hickson (ian@hixie.ch)
Date: 2004-02-16
Archive: http://www.w3.org/mid/Pine.LNX.4.58.0402161755520.2210@dhalsim.dreamhost.com
On Mon, 16 Feb 2004, Boris Zbarsky wrote: >> >> The working group hasn't yet discussed this, but would changing 'height' >> to 'outer height' be satisfactory for you? > > How about "margin-box height"? Ok, 'margin-box height' it is. Thanks, -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Tantek Çelik (tantek@cs.stanford.edu)
Date: 2004-02-16
Archive: http://www.w3.org/mid/BC565859.36759%25tantek@cs.stanford.edu
On 2/16/04 11:07 AM, "Bjoern Hoehrmann" <derhoermi@gmx.net> wrote: > * Tantek Çelik wrote: >> [...] > > You are just telling me it does not matter what features beyond > those of CSS 1.0 are included in CSS 2.1 and I disagree. This specific comment is a new comment and thus I believe it will not be considered as a LC comment for CSS2.1. >> At this point the working group considers this issue closed. > > I assume you mean by considering it closed that the Working Group will > report my objection to the Director in their request for advancement. By considering it closed we mean that the points raised in your previous emails in this thread have been responded to. Please quote and cite with URL predating the CSS 2.1 LC deadline what you consider your objection to be, because otherwise, the group believes all your objections have been responded to and properly explained. Thanks, Tantek
From: Ian Hickson (ian@hixie.ch)
Date: 2004-02-16
Archive: http://www.w3.org/mid/Pine.LNX.4.58.0402161648460.2210@dhalsim.dreamhost.com
On Thu, 12 Feb 2004 staffan.mahlen@comhem.se wrote: > > Interesting. The top of a box in the subtree in the last sentence of > the paragraph would be the top content edge i assume? No, it would be the top of the line-height, as for the other vertical alignment values. The "top of the box" wording is used identically for several of the vertical-align values. > I have also been thinking about whether introducing a 'line-spacing' > property might reduce the issues with 'line-height'. I'm not really sure I understand which "issues" this (or your alternate inline box model) would solve. > <a href="dummy" style="border: solid"><img src="dummy.png"/></a> > > where the a-box would in this model be high enough to potentially be > the thing you click on when activating the link as you press the > image. This seems like a good thing to me. Why? The click already bubbles to the <a>. > Another example that would seem to work better in a model like the > above is of course > Text row one</br> > <span style="border-top: solid .5em">Text row two</span> > but that is for obvious reasons never used. I don't understand what this is trying to show. -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Tantek Çelik (tantek@cs.stanford.edu)
Date: 2004-02-16
Archive: http://www.w3.org/mid/BC5690FE.367D8%25tantek@cs.stanford.edu
On 2/16/04 2:25 PM, "Bjoern Hoehrmann" <derhoermi@gmx.net> wrote: > > * Tantek Çelik wrote: >>>>> I assume you mean by considering it closed that the Working Group will >>>>> report my objection to the Director in their request for advancement. >>>> >>>> By considering it closed we mean that the points raised in your previous >>>> emails in this thread have been responded to. >>> >>> Ok. >>> >>>> Please quote and cite with URL predating the CSS 2.1 LC deadline what you >>>> consider your objection to be, because otherwise, the group believes all >>>> your objections have been responded to and properly explained. >>> >>> I am just pointing out that your response does not remove my objection. >> >> I am just pointing out that by failing to provide a quote and cite with URL >> predating the CSS 2.1 LC deadline with what you consider your objection to >> be, you have removed your objection. > > I may register formal objection at *any time* The working group has no obligation to report even the existence of responses/objections made after the last call review deadline. > and I obviously cannot > register formal objection prior to the review deadline if I object to a > response of the Working Group that is sent past this deadline, hence I > do not understand how the Last Call Review Deadline is relevant here. It is relevant in that the only objections the working group must respond to are those made before the last call deadline. New objections, even if they are made in the middle of some other thread, do not require a response. > I > neither understand why I need to point you at my formal objection Because again, you failed to quote it as requested. You simply provided two URLs to messages which have already been responded to. > > http://lists.w3.org/Archives/Public/www-style/2004Feb/0102.html Response: http://lists.w3.org/Archives/Public/www-style/2004Feb/0103.html > http://lists.w3.org/Archives/Public/www-style/2004Feb/0107.html Response: http://lists.w3.org/Archives/Public/www-style/2004Feb/0307.html > I sent it to the list in response to what I object to, that should be > absolutely sufficient. And the working group replied and explained away your objections, which is sufficient. If you don't think so, it is your burden to provide the specific objection quote and URL. Thanks, Tantek
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-16
Archive: http://www.w3.org/mid/200402161730.i1GHUrOC012037@nerd-xing.mit.edu
> The working group hasn't yet discussed this, but would changing 'height'
> to 'outer height' be satisfactory for you?
How about "margin-box height"? But yes, "outer height" may be better (though I
don't recall that term being defined in the spec either, and using terms that
are not defined with the assumption that everyone will understand what they
mean is just a bad idea, in my opinion).
Boris
--
Washington [D.C.] is a city of Southern efficiency and
Northern charm.
-- John F. Kennedy
From: Tantek Çelik (tantek@cs.stanford.edu)
Date: 2004-02-16
Archive: http://www.w3.org/mid/BC5645EC.3673F%25tantek@cs.stanford.edu
On 2/10/04 11:07 AM, "Bjoern Hoehrmann" <derhoermi@gmx.net> wrote: > > * Ian Hickson wrote: >> The other part states that features that have not been adequately tested >> will be dropped. Are you seriously suggesting that you would want features >> that have not received adequate interoperability testing to remain in the >> specification? Isn't that violating the spirit of the process document >> (and the whole _point_ of a CR stage) much more than the given criteria? > > The Process document requires to precisely identify features considered > at risk to ensure that the Proposed Recommendation does not invalidate > an individual's review or implementation experience of the Candidate > Recommendation. That requirement has been satisfied. The expression "any features not in CSS1" is a precise set. > A technical report should not advance within the > Recommendation track without further work if the Working Group is not > able to demonstrate that each feature of the technical report has been > implemented. Agreed. Thus such features may also be dropped. > The proposed exit criteria allow dropping features just for the sake of > advancement. I do not want to say that this is the intent of the > proposed exit criteria, my point is just that a Working Group should not > have a blank check to do so. Not a "blank check". This only applies to features that were not in CSS1. > If implementors have simply not gotten around to implement a perfectly > fine section of the specification, the perfectly fine section should not > get dropped, Such "perfectly fine sections" will be dropped from CSS2.1 and moved to the appropriate CSS3 module(s). > the Working Group should rather wait with its request for > advancement; Which is what the working group will do with the CSS3 modules. > it may also request advancement without demonstrating > implementation experience. This is a very bad idea, and should be avoid by all working groups. Specifications without demonstrated implementation experience have proven to be very problematic, e.g. CSS2. > The Working Group should encourage complete implementations of the > technical report, The CR draft will do so. > the proposed exit criteria however do not do so; That is the wrong place to state encouragement. > it > does not seem unreasonable for implementors to expect that the Working > Group drops the features they do not implement and they would still > conform to the specification. No that is unreasonable, as there are several implementors implementing. Only two implementors need to produce interoperable implementations in order for the feature to remain. And which two implementation those are can be different from feature to feature. > If it is forseeable that the exit criteria will not be met due to a > specific feature, it would also be reasonable to go back to Last Call > with the feature removed, demonstrate implementations and request > advancement of the technical report, without losing time or considerable > additional work. The working group prefers to complete in CSS2.1 in a timely manner, and move such features to CSS3. > The difference is that reviewers would have a chance to > object to the removal of the feature, as they would have if the exit > criteria precisely identify features considered at risk, which is all I > have asked for. The list was precisely identified, "features that are not in CSS1". Reviewers have had a chance to object. At this point the working group considers this issue closed. Thanks for your feedback. Tantek Çelik for the CSS WG
From: Ian Hickson (ian@hixie.ch)
Date: 2004-02-16
Archive: http://www.w3.org/mid/Pine.LNX.4.58.0402161501270.2210@dhalsim.dreamhost.com
On Tue, 10 Feb 2004 staffan.mahlen@comhem.se wrote:
>
> While i must admit to more or less agreeing to the first part of the
> above sentence, i don't quite understand the second.
Take:
p, table { border: solid; }
img { float: left; }
<p> <img ...> ... </p>
<table> ... </table>
Most authors seem to want:
+--------------------+
| +---+ ... |
+-| |--------------+
| | +---------+
| | | |
+---+ | |
| |
...rather than:
+--------------------+
| +---+ ... |
+-| |--------------+
| |
| |
+---+
+---------+
| |
| |
In any case, if they want the latter, they can always get it by setting
clear:left on the table.
HTH,
--
Ian Hickson )\._.,--....,'``. fL
U+1047E /, _.. \ _\ ;`._ ,.
http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Bjoern Hoehrmann (derhoermi@gmx.net)
Date: 2004-02-16
Archive: http://www.w3.org/mid/40540e79.349908081@smtp.bjoern.hoehrmann.de
* Tantek Çelik wrote: >[...] You are just telling me it does not matter what features beyond those of CSS 1.0 are included in CSS 2.1 and I disagree. >At this point the working group considers this issue closed. I assume you mean by considering it closed that the Working Group will report my objection to the Director in their request for advancement.
From: Ian Hickson (ian@hixie.ch)
Date: 2004-02-17
Archive: http://www.w3.org/mid/Pine.LNX.4.58.0402171526230.14033@dhalsim.dreamhost.com
On Tue, 10 Feb 2004, Boris Zbarsky wrote: > > Bert Bos wrote: > > Section 8.5.4 (Border shorthand properties: 'border-top', > > 'border-bottom', 'border-right', 'border-left', and 'border') > > <http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#border-shorthand-properties> > > The heading should list top, right, bottom, left in that order, > > probably. > > > > CSS WG response: > > Not changed. > > Again, may I inquire why? The top-right-bottom-left order is the > standard order for all side-related things in CSS; listing things in a > different order is very confusing to readers, who then waste time trying > to figure out why the order was changed in this one instance. Fair enough. We'll make the change for you. Cheers, -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Bert Bos (bert@w3.org)
Date: 2004-02-17
Archive: http://www.w3.org/mid/16434.31687.655120.182477@lanalana.inria.fr
Section 5.12.1 already contains this text:
A UA should act as if the fictional start tag of the first-line
pseudo-element is just inside the smallest enclosing block-level
element. (Since CSS1 and CSS2 were silent on this case, authors
should not rely on this behavior.) Here is an example. The
fictional tag sequence for
<DIV>
<P>First paragraph</P>
<P>Second paragraph</P>
</DIV>
is
<DIV>
<P><DIV:first-line><P:first-line>First paragraph</P:first-line></DIV:first-line></P>
<P><P:first-line>Second paragraph</P:first-line></P>
</DIV>
That seems to define exactly what you want.
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos/ W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-17
Archive: http://www.w3.org/mid/4032A9C9.8050309@mit.edu
Bert Bos wrote:
> 1. HTTP header
> 2. BOM
> 3. @charset
> 4. etc.
>
> But this is complicated material, so: does anybody see a problem with
> this?
Sure. Different encodings can have the same BOM (eg UTF-16 and UCS-2,
but there may also be other cases that are not quite so trivial).
In case anyone is interested in what Mozilla does right now, the basic
algorithm for this step is:
1) Check for a BOM. If there is one, set the "generic encoding family"
(# of bytes per ASCII character and byte order based on that).
2) If there is no BOM, see whether the first couple of bytes look like
a '@' in some random encoding. If they do, set the "generic
encoding family" based on what it looks like.
3) If there was a '@' try to parse the whole @charset rule using the
"generic encoding family" info to find the actual ascii chars (eg
for UTF-16/UCS-2/whatever, look at every other byte).
4) If there wasn't an @charset rule but we got a "generic encoding
family" based on the BOM, go with the most common or inclusive
charset we know of that fits those criteria (eg we would go with
UTF-16 over UCS-2)
Steps 1, 2, 3 are basically what the XML 1.0 spec describes as the way
to handle XML decls and BOMs (this is the spec that's references in the
encoding selection section of CSS2, iirc).
-Boris
From: Ian Hickson (ian@hixie.ch)
Date: 2004-02-17
Archive: http://lists.w3.org/Archives/Public/www-style/2004Feb/0317.html
On Sat, 14 Feb 2004, David Woolley wrote: >> >> # For XHTML and other languages written in XML, no attribute >> # should be considered presentational. The styling of elements and > > I would say most attributes in SVG were presentational! We have changed that text to read: | For other languages, all document language-based styling should be | handled in the user agent style sheet. -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: L. David Baron (dbaron@dbaron.org)
Date: 2004-02-17
Archive: http://www.w3.org/mid/20040217223733.GA5825@darby.dbaron.org
On Monday 2003-10-20 12:09 -0400, fantasai wrote: > S6.2: Inheritance > > # When inheritance occurs, elements inherit computed values. The > # computed value from the parent element becomes both the specified > # value and the computed value on the child. > ... > # Each property may also have a specified value of 'inherit', which > # means that, for a given element, the property takes the same > # computed value as the property for the element's parent. > > There's a dichotomy in how the "specified value" for inherited values > works, depending on whether it's explicit or implied. It would be best > if the initial behavior of 'color' and "color: inherit" meant exactly > the same thing. And this way the meaning of "color: inherit" on the > root element would follow from the inheritance logic without having to > be handled as another exception. The working group doesn't want to change this at this time. The rules on how inheritance applies to specified and computed values can have complicated effects and have been checked to ensure that they lead to the outcome we expect. In particular, these rules have not been modified since CSS2. My original proposal for changing the way computed values work actually removed this dichotomy -- it made the specified value always be the computed value of the parent, which seemed rather ugly, but I wanted to avoid having to deal with 'inherit' in every "Computed Value:" line. However, someone else came up with a better solution in what's now the third paragraph of section 6.1.2 [1]. If we were to fix this now, I'd much prefer making the specified value consistently be 'inherit'. This would require, at a minimum, changes to 6.1.1 and 6.2.1. However, the changes to 6.2.1 would introduce another inconsistency that couldn't be fixed until CSS3 -- an inconsistency between the second and third bullets in 6.1.1. (CSS3's 'initial' value could be used in the third bullet point.) Since this change doesn't fix any real problems and is the type of change that might introduce inconsistencies in other parts of the spec that we won't find for a long time, I think it's better not to make the change. -David [1] http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#computed-value -- L. David Baron <URL: http://dbaron.org/ >
From: Ian Hickson (ian@hixie.ch)
Date: 2004-02-17
Archive: http://www.w3.org/mid/Pine.LNX.4.58.0402171524260.14033@dhalsim.dreamhost.com
On Tue, 10 Feb 2004, Boris Zbarsky wrote: >> >> Unlike margin and border, conforming HTML user agents _do_ have to >> apply padding to <html>? >> >> CSS WG response: >> Yes. > > May I ask why? Pardon the frankness, but that's a pretty wacky thing to > require (or allow, depending on the viewpoint). Either <html> is > special and <body> is treated as the root, or <html> is just a block, I > would think.... Upon further reflexion, the working group has decided to rescind it's previous decision and remove the two aforementioned caveats altogether. Cheers, -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Bert Bos (bert@w3.org)
Date: 2004-02-17
Archive: http://www.w3.org/mid/16434.33648.835633.693769@lanalana.inria.fr
I wrote: > Your e-mail: > http://www.w3.org/mid/3F9408C5.2040507@escape.com > > S6.4.3: Calculating a selector's specificity > http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#specificity > # Concatenating the four numbers a-b-c-d (in a number system with > # a large base) gives the specificity. > > Use of dashes here doesn't match use of commas in the examples. > > CSS WG response: > Changed. Sorry, that should have been "not changed". We think the dashes and the commas read well, better than when one would be changed into the other. Bert -- Bert Bos ( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos/ W3C/ERCIM bert@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Ian Hickson (ian@hixie.ch)
Date: 2004-02-17
Archive: http://www.w3.org/mid/Pine.LNX.4.58.0402172347440.2286@dhalsim.dreamhost.com
fantasai wrote: > I don't see why. The sections on the width and height > of absolutely positioned, replaced elements offer details > on the interpretation of 'auto' as well. Fair enough. We'll make the change. -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Boris Zbarsky (bzbarsky@MIT.EDU)
Date: 2004-02-17
Archive: http://www.w3.org/mid/200402172058.i1HKwk6J018767@no-knife.mit.edu
> A UA should act as if the fictional start tag of the first-line > pseudo-element is just inside the smallest enclosing block-level > element. > <DIV> > <P><DIV:first-line><P:first-line>First paragraph</P:first-line></DIV: > first-line></P> > <P><P:first-line>Second paragraph</P:first-line></P> > </DIV> > > That seems to define exactly what you want. Not quite. Notice, for example, that the <P:first-line> tag is _not_ in fact "just inside the smallest enclosing block-level element". It's inside the <DIV:first-line> (which _is_ just inside, etc). So clearly the above rule doesn't apply when multiple first-line pseudo-elements are involved..... Why and how does it apply when first-letter is involved? The spec doesn't say. I understand that if you already know what the spec is trying to say then it's not too hard to figure out what these statements and examples really mean. But if you _don't_ know what it's trying to say, there is enough internal inconsistency and lack of clarity that it's hard to tell what it's really saying. Boris -- A computer lets you make more mistakes faster than any invention in human history, with the possible exceptions of handguns and tequila.
From: Ian Hickson (ian@hixie.ch)
Date: 2004-02-17
Archive: http://www.w3.org/mid/Pine.LNX.4.58.0402171356590.14033@dhalsim.dreamhost.com
On Fri, 13 Feb 2004, fantasai wrote: >> >> # In this process, non-textual entities such as images are treated >> # as neutral characters >> >> as object replacement characters (U+FFFC) >> >> CSS WG response: >> We don't see why this is useful. > > It gives a more precise link to the desired behavior in bidi reordering. How is it more precise? To me it seems more indirect. -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Ian Hickson (ian@hixie.ch)
Date: 2004-02-17
Archive: http://www.w3.org/mid/Pine.LNX.4.58.0402172357590.2286@dhalsim.dreamhost.com
On Tue, 17 Feb 2004, Boris Zbarsky wrote:
>
> Sure. Different encodings can have the same BOM (eg UTF-16 and UCS-2,
> but there may also be other cases that are not quite so trivial).
This case is not a problem -- since UTF-16 is a superset of UCS-2, simply
treat it as UTF-16.
But in any case, the change Bert mentioned doesn't remove the previous
text, which says:
| If an external style sheet has U+FEFF ("zero width non-breaking space")
| as the first character (i.e., even before any @charset rule), this
| character is interpreted as a so-called "Byte Order Mark" (BOM), as
| follows:
|
| * If the style sheet is encoded as "UTF-16" [RFC2781] or "UTF-32"
| [UNICODE], the BOM determines the byte order (e.g. "big-endian" or
| "little-endian") as explained in the cited RFC.
| * If the style sheet is encoded as anything else, the U+FEFF
| character is ignored.
This doesn't conflict with the steps Bert mentioned, but it does clarify
that @charset is still relevant even if there is a BOM.
(The text "BOM" in the steps links straight to this text.)
The text before the steps says that "user agents must observe the
following priorities when determining a style sheet's character encoding
(from highest priority to lowest)". So as long as a later step doesn't
contradict an earlier one, it is still applicable.
> In case anyone is interested in what Mozilla does right now, the basic
> algorithm for this step is: [...]
A. What happens if you have a UTF-16 BOM, and an @charset encoded as
UTF-16 which claims it is ISO-8859-1?
B. Or no BOM, US-ASCII encoded @charset which claims to be UCS-4?
C. Or UTF-8 BOM followed by US-ASCII @charset claiming ISO-8859-1?
D. A UTF-16 BOM with no @charset being linked from a stylesheet or
document that is known to be in UCS-2?
E. a document whose odd bytes spell a US-ASCII @charset claiming UTF-16BE
and whose even bytes spell a US-ASCII @charset claiming UTF-16LE, linked
from a document or stylesheet claiming UTF-8?
etc.
These are the cases that these steps are partially clarifying. Per the
text currently in the spec which we hope to have go to CR, in case A the
UA would use UTF-16 (the BOM trumps the @charset), case B is undefined,
case C would use UTF-8, case D would use UTF-16 (it can't be UCS-2, since
if it was the BOM would have to be ignored per the text quoted above, and
the BOM comes before linking metadata in the list), and case E would use
UTF-8 (since the start doesn't contain an @charset rule in any character
encoding).
Case B will be covered by CSS3 Syntax.
--
Ian Hickson )\._.,--....,'``. fL
U+1047E /, _.. \ _\ ;`._ ,.
http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Bert Bos (bert@w3.org)
Date: 2004-02-17
Archive: http://www.w3.org/mid/16434.32592.921798.559429@lanalana.inria.fr
Boris Zbarsky writes: > > Bert Bos wrote: > > Your e-mail: > > http://www.w3.org/mid/200309282304.h8SN40r2004872@nerd-xing.mit.edu > > > > Section 6.4.4 (Precedence of non-CSS presentational hints) "type" > > is not presentational in some cases, but presentational in others > > (on <ol>, <ul>, <li>, to be precise). > > > > CSS WG response: > > > > We don't consider TYPE on lists to be presentational the same way > > as COLOR or FONT are. > > Why not, exactly? If it's not presentational, why is there a CSS > property that has the same effect? Because the type attribute defines the authors intention (the meaning) and the property the actual appearance. It might be that type=a gets displayed as 'list-style: lower-greek' in a Greek document. But that is maybe unnecessarily subtle: so we accept your comment and added "(except on LI, OL and UL elements)" after "type" in the list in section 6.4.4. Bert -- Bert Bos ( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos/ W3C/ERCIM bert@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-17
Archive: http://lists.w3.org/Archives/Public/www-style/2004Feb/0335.html
As I wrote in the response to issues 115 and 44, CSS 2.1 will allow a BOM (Byte Order Mark) to occur in an external style sheet and UAs can use it (1) to determine the byte ordering if they know the encoding but not the byte order, and (2) determine the encoding itself, if there is no more authoritative source for it (in particular HTTP headers). So the list of places to look for encoding info was as follows: 1. HTTP header 2. @charset 3. BOM 4. etc. But some people pointed out that the BOM, if present, comes before the @charset, so in fact you always have to check it first. It seems therefore, that the order of (2) and (3) in the list doesn't matter. And thus, we want to change it to: 1. HTTP header 2. BOM 3. @charset 4. etc. But this is complicated material, so: does anybody see a problem with this? There doesn't seem to be an encoding in which the "@" looks like the BOM of some other encoding. Did we overlook anything? Bert -- Bert Bos ( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos/ W3C/ERCIM bert@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-17
Archive: http://www.w3.org/mid/16434.33059.22990.896833@lanalana.inria.fr
Boris Zbarsky writes: > > Bert Bos wrote: > > Your e-mail: > > http://www.w3.org/mid/200309282315.h8SNFiEh006969@nerd-xing.mit.edu > > Section 7.3 (Recognized media types) > > <http://www.w3.org/TR/2003/WD-CSS21-20030915/media.html#media-types> > > CSS WG response: > > > > Reworded the text: "names of media types are normative, but the > > parenthetical descriptions are informative. > > Those aren't really parenthetical descriptions; they're just > descriptions.... The intent was that only the parenthetical remarks would be informative, but it seems nothing is lost if the whole description is informative. So we accept your comment and removed the word "parenthetical". Bert -- Bert Bos ( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos/ W3C/ERCIM bert@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Ian Hickson (ian@hixie.ch)
Date: 2004-02-17
Archive: http://www.w3.org/mid/Pine.LNX.4.58.0402172352190.2286@dhalsim.dreamhost.com
fantasai wrote: > s/clearance/float clearance/ Changing it just in one place would be more confusing, we think (using two terms for one concept), and changing it in multiple places would make the text a lot harder to read, we think (and this text is already quite verbose enough as it is). Since the first occurance of clearance links straight to the definition, we really don't see that it is much of a problem. -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
From: Bert Bos (bert@w3.org)
Date: 2004-02-18
Archive: http://www.w3.org/mid/16435.26816.6696.770444@lanalana.inria.fr
Boris Zbarsky writes: > > Bert Bos wrote: > > [This is a response to the response to issue 44 as well.] > > The new text reads: > > Great! I have one tiny little nit... > > > 5. charset of referring document (if any) > > The referring thing could also be a stylesheet, of course (@import > rules), in which case I would think this should be the charset of that > stylesheet. Accepted. Added "...referring _stylesheet or_ document..." (Now please implement it, because we're not sure that many browsers actually work like that, currently. And if we don't find two that do, we'll have to take it out again before making CSS 2.1 a Recommendation :-) ) Bert -- Bert Bos ( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos/ W3C/ERCIM bert@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
From: Bert Bos (bert@w3.org)
Date: 2004-02-23
Archive: http://www.w3.org/mid/16442.20892.588427.737747@lanalana.inria.fr
Boris Zbarsky writes: > > > A UA should act as if the fictional start tag of the first-line > > pseudo-element is just inside the smallest enclosing block-level > > element. > > > <DIV> > > <P><DIV:first-line><P:first-line>First paragraph</P:first-line></DIV: > > first-line></P> > > <P><P:first-line>Second paragraph</P:first-line></P> > > </DIV> > > > > That seems to define exactly what you want. > > Not quite. Notice, for example, that the <P:first-line> tag is _not_ in fact > "just inside the smallest enclosing block-level element". It's inside the > <DIV:first-line> (which _is_ just inside, etc). > > So clearly the above rule doesn't apply when multiple first-line pseudo-elements > are involved..... Why and how does it apply when first-letter is involved? > The spec doesn't say. > > I understand that if you already know what the spec is trying to say then it's > not too hard to figure out what these statements and examples really mean. But > if you _don't_ know what it's trying to say, there is enough internal > inconsistency and lack of clarity that it's hard to tell what it's really > saying. Maybe the text isn't beautiful and we can see if the readability can be improved before the spec becomes a Recommendation, but we think it already says how multiple first-lines combine, and how first-line and first-letter combine; how multiple first-lines and multiple first-letters combine can be inferred. We don't want to change anything now that isn't broken. Bert -- Bert Bos ( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos/ W3C/ERCIM bert@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France