headers
Ian Hickson | 1 Mar 2007 02:45
Picon

Re: List selector and class attribute


On Wed, 23 Mar 2005, Allan Sandfeld Jensen wrote:
> On Tuesday 22 March 2005 02:54, Ian Hickson wrote:
> > On Mon, 21 Mar 2005, Allan Sandfeld Jensen wrote:
> > > 	Or should HTML attributes be white-space transformed so only
> > > spaces remain.
> >
> > This actually should already happen. Per SGML parsing rules, U+000A, 
> > U+000D, and U+0020 all either get stripped or turn into U+0020.
> 
> Thanks, I finally found it. Looking up standards that are not fully open 
> and cost money sucks. Hopefully this detail can be added to the appendix 
> of HTML in next revision?

Actually for compatibility with existing browsers, the above requirement 
has been dropped in the HTML5 parser specification. U+000D now turns into 
U+000A, but U+000A and U+0020 are preserved in quoted attributes.

   http://www.whatwg.org/specs/web-apps/current-work/#attribute2

>From the WHATWG "replying to old e-mails everyone has forgotten about" 
department,
--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Permalink | Reply | 1 comment |
headers
Allan Sandfeld Jensen | 1 Mar 2007 07:47

Re: List selector and class attribute


On Thursday 01 March 2007 02:45, you wrote:
> On Wed, 23 Mar 2005, Allan Sandfeld Jensen wrote:
> > On Tuesday 22 March 2005 02:54, Ian Hickson wrote:
> > > On Mon, 21 Mar 2005, Allan Sandfeld Jensen wrote:
> > > > 	Or should HTML attributes be white-space transformed so only
> > > > spaces remain.
> > >
> > > This actually should already happen. Per SGML parsing rules, U+000A,
> > > U+000D, and U+0020 all either get stripped or turn into U+0020.
> >
> > Thanks, I finally found it. Looking up standards that are not fully open
> > and cost money sucks. Hopefully this detail can be added to the appendix
> > of HTML in next revision?
>
> Actually for compatibility with existing browsers, the above requirement
> has been dropped in the HTML5 parser specification. U+000D now turns into
> U+000A, but U+000A and U+0020 are preserved in quoted attributes.
>
>    http://www.whatwg.org/specs/web-apps/current-work/#attribute2
>
> From the WHATWG "replying to old e-mails everyone has forgotten about"
> department,

Yes I know. Of course the unspoken consequence of compatible attribute parsing 
is that CSS list selector can accept new-lines separated classes.

This way HTML5 needs the following update in CSS 2.1:

s/space/whitespace/ on
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jukka K. Korpela | 1 Mar 2007 10:44
Picon
Picon

[CSS3 Text] Optional indication of line continuation

As currently drafted (and as implemented in IE), word-wrap: break-word 
involves no indication that a break has occurred. This might be fine for 
e.g. a URL with delimiters like "<" and ">" or for a fragment of DNA code,
but for many other code-like notations the emergency breaks might create 
uncertainty: when I see "l9:" at the end of a line and "#¤%" at the start 
of the next line, does it mean "l9: #¤%" or "l9:#¤%"?

In programming languages, a trailing backslash "\" is often used at the end of 
line to indicate that the string continues immediately at the start of the next 
line. Although cryptic to many laymen, such notations can be very useful in 
some contexts. Besides, when break-word is really applied to words, a trailing 
"\" might even give an intuitive idea of what has happened.

Hence, I'd suggest a property called continuation-indicator, with a string 
value, with the empty string as the initial value. It would specify the string 
(typically, one character) to be appended to a line when word-wrap: break-word 
has caused an otherwise unbreakable string to be broken. A browser needs to 
take the length of this string into account when computing where to break a 
string in the document content. Typical values that might be used in different 
contexts are "\", "-", "...", and " (cont'd)".

I think this would be easy to define and to implement. Whether it is 
useful enough is a different issue.

And then there's the tougher issue: when a break occurs after a special 
character due to applying Unicode line breaking rules, should there be a 
similar option to indicate that a break has occurred, e.g. that "-" at the 
end of a line and "1" at the start of the next line should really be read
as "-1" rather than as "- 1"?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eli Friedman | 1 Mar 2007 19:14
Picon
Favicon

Expected overflow behavior for element with clip set?


(Resending because it apparently got lost the first
time.)

Given the following HTML:
<style>
..parent {overflow: auto; position: relative;
         height: 100px; width: 100px}
..child {background: blue; position: absolute;
        clip: rect(0pt, 50px, 50px, 0pt);
        width: 200px; height: 200px;}
</style>
<div class=parent>
  <div class=child></div>
</div>

Is the browser expected to show scrollbars (or
whatever equivalent scrolling mechanism)?

Every browser on my computer (Opera 9, IE 6, Firefox)
shows scrollbars in this situation.  However, there
isn't actually anything there because it's been
clipped out.

I've written a patch for Firefox that changes the
behavior to only show a scrolling mechanism if there
is visible content to scroll to.  This changes the
behavior so that scrollbars no longer appear on my
testcase above.  This seems like a much more
appropriate interpretation of the specification, but
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rainer Åhlfors | 2 Mar 2007 18:24

RE: Expected overflow behavior for element with clip set?


http://www.w3.org/TR/REC-CSS2/visufx.html#overflow
Initial value of 'overflow': 'visible'

http://www.w3.org/TR/REC-CSS2/visufx.html#clipping
The 'clip' property applies to elements that have a 'overflow' property with
a value other than 'visible'.

Not to mention the fact that you are defining a height and width for the
child element.

This is not a bug or a problem. It is a misinterpretation of the CSS
specification on your part, resulting in an incomplete and misleading test.

 
Rainer Åhlfors

-----Original Message-----
From: www-style-request <at> w3.org [mailto:www-style-request <at> w3.org] On Behalf
Of Eli Friedman
Sent: Wednesday, February 28, 2007 4:27 PM
To: www-style <at> w3.org
Subject: Expected overflow behavior for element with clip set?

Given the following HTML:
<style>
..parent {overflow: auto; position: relative;
         height: 100px; width: 100px}
..child {background: blue; position: absolute;
        clip: rect(0pt, 50px, 50px, 0pt);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rainer Åhlfors | 2 Mar 2007 18:43

RE: Expected overflow behavior for element with clip set?


I will agree that it is a problem with the spec as written. Specifically
this part:
"A clipping region defines what portion of an element's rendered content is
visible."

It essentially implies that the area outside the clipping region is treated
as 'visibility: hidden'. This explains the presence of scroll bars.

While I agree that the behavior is not desirable, and that this portion of
the spec should be re-written to indicate this, I would in fact maintain my
position that it is not a _browser_ bug. The browsers seem to handle the
scenario exactly as you would expect, given the information presented
within.

Be they Gecko layout developers or not, and CSS WG members or not -- the
spec as written today supports the behavior of the browsers. Hence, it is
not a browser bug. That's all I was saying.

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky <at> MIT.EDU] 
Sent: Friday, March 02, 2007 10:31 AM
To: rahlfors <at> wildcatsoftware.net
Subject: Re: Expected overflow behavior for element with clip set?

Rainer Åhlfors wrote:
> http://www.w3.org/TR/REC-CSS2/visufx.html#overflow
> Initial value of 'overflow': 'visible'
> 
> http://www.w3.org/TR/REC-CSS2/visufx.html#clipping
(Continue reading)

Permalink | Reply | 6 comments |
headers
Boris Zbarsky | 2 Mar 2007 20:18
Picon
Favicon

Re: Expected overflow behavior for element with clip set?


Rainer Åhlfors wrote:
> the spec as written today supports the behavior of the browsers. Hence, it is
> not a browser bug.

No one ever claimed it's a browser bug.  The mail you were responding to 
was a comment on the spec, not on implementations.

-Boris
Permalink | Reply | 5 comments |
headers
Rainer Åhlfors | 2 Mar 2007 22:42

RE: Expected overflow behavior for element with clip set?


https://bugzilla.mozilla.org/show_bug.cgi?id=372037 

Clearly, the OP disagrees.

 
Rainer

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky <at> MIT.EDU] 
Sent: Friday, March 02, 2007 12:19 PM
To: rahlfors <at> wildcatsoftware.net
Cc: www-style <at> w3.org
Subject: Re: Expected overflow behavior for element with clip set?

Rainer Åhlfors wrote:
> the spec as written today supports the behavior of the browsers. Hence, it
is
> not a browser bug.

No one ever claimed it's a browser bug.  The mail you were responding to 
was a comment on the spec, not on implementations.

-Boris
Permalink | Reply | 0 comments |
headers
Rainer Åhlfors | 2 Mar 2007 22:47

RE: Expected overflow behavior for element with clip set?


I just want to make sure we are clear with regards to any future discussion,
and differentiating between browser bugs (as in, incorrect implementation of
spec in browser) and undesired browser behavior (as in, spec is vague or
unclear, causing expected user behavior not to align with spec, as is the
case with this scenario).

 
Rainer

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky <at> MIT.EDU] 
Sent: Friday, March 02, 2007 12:19 PM
To: rahlfors <at> wildcatsoftware.net
Cc: www-style <at> w3.org
Subject: Re: Expected overflow behavior for element with clip set?

Rainer Åhlfors wrote:
> the spec as written today supports the behavior of the browsers. Hence, it
is
> not a browser bug.

No one ever claimed it's a browser bug.  The mail you were responding to 
was a comment on the spec, not on implementations.

-Boris
Permalink | Reply | 3 comments |
headers
Eli Friedman | 2 Mar 2007 23:14
Picon
Favicon

RE: Expected overflow behavior for element with clip set?


That's about right; the specification isn't really
clear about what to do, which is why I'm bringing it
up here instead of just changing the bahavior.  If the
correct behavior was clear, there would be no need to
discuss it.

-Eli

--- Rainer Åhlfors <rahlfors <at> wildcatsoftware.net>
wrote:

> 
> I just want to make sure we are clear with regards
> to any future discussion,
> and differentiating between browser bugs (as in,
> incorrect implementation of
> spec in browser) and undesired browser behavior (as
> in, spec is vague or
> unclear, causing expected user behavior not to align
> with spec, as is the
> case with this scenario).
> 
>  
> Rainer
> 
> -----Original Message-----
> From: Boris Zbarsky [mailto:bzbarsky <at> MIT.EDU] 
> Sent: Friday, March 02, 2007 12:19 PM
> To: rahlfors <at> wildcatsoftware.net
(Continue reading)

Permalink | Reply | 2 comments |

Gmane