headers
Matthew Raymond | 1 Aug 2005 03:11
Picon
Favicon

Re: [WF2] Readonly and default pseudoclass matching

Ian Hickson wrote:
> On Sun, 31 Jul 2005, Matthew Raymond wrote:
>>Ian has sadly chosen to change the text to this:
>>| Matches form control elements that have the readonly attribute set,
>>| and to which the readonly attribute applies (thus radio buttons will
>>| never match this, regardless of the value of the attribute), as well
>>| as elements defined by this specification that are not form controls
>>| (namely form, label, datalist, option, optgroup, and fieldset
>>| elements).
>>
>>   First of all, he shouldn't mention "elements...that are not form 
>>controls" in the first place, because he's saying that they can be 
>>specifically selected by :read-only when the whole point should have 
>>been to eliminate anything that might conflict with CSS3-UI, and 
>>obviously if we change CSS3-UI to use the XForms definition of 
>>:read-only, this will conflict.
> 
> Note that the text above was reviewed by the editor of the CSS3 UI spec 
> and given the all-clear.

   Of course he gave it the all clear. He's the one who wrote the
disputed portion of the spec in the first place.

> CSS3 UI is pretty clear about the fact that pretty much all elements match 
> either :read-only or :read-write, for example is a document is loaded in 
> an editor (say, Amaya), all elements become :read-write.

   And if it's changed later, say in a CSS3-UI Revision 1, you'll have
to change the language in WF2 to follow suit, because WF2 deliberately
reiterates parts of the current CSS3-UI.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Ian Hickson | 1 Aug 2005 03:25
Picon

Re: [WF2] Readonly and default pseudoclass matching

On Sun, 31 Jul 2005, Matthew Raymond wrote:
> >>
> >>Ian has sadly chosen to change the text to this:
> >>| Matches form control elements that have the readonly attribute set,
> >>| and to which the readonly attribute applies (thus radio buttons will
> >>| never match this, regardless of the value of the attribute), as well
> >>| as elements defined by this specification that are not form controls
> >>| (namely form, label, datalist, option, optgroup, and fieldset
> >>| elements).
> >>
> >>   First of all, he shouldn't mention "elements...that are not form 
> >>controls" in the first place, because he's saying that they can be 
> >>specifically selected by :read-only when the whole point should have 
> >>been to eliminate anything that might conflict with CSS3-UI, and 
> >>obviously if we change CSS3-UI to use the XForms definition of 
> >>:read-only, this will conflict.
> > 
> > Note that the text above was reviewed by the editor of the CSS3 UI spec 
> > and given the all-clear.
> 
> Of course he gave it the all clear. He's the one who wrote the disputed 
> portion of the spec in the first place.

Which disupted section of which spec? If there is a dispute about a CSS 
spec, this is the wrong forum. Please move such discussions to www-style, 
where the discussions have a greater-than-zero chance of actually causing 
the CSS specs to change. :-)

If the disputed section is the one I wrote (i.e. the one quoted above) 
then no, he didn't; I wrote it.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Matthew Raymond | 1 Aug 2005 04:57
Picon
Favicon

Re: [WF2] Readonly and default pseudoclass matching

Ian Hickson wrote:
> On Sun, 31 Jul 2005, Matthew Raymond wrote:
>>>>Ian has sadly chosen to change the text to this:
>>>>| Matches form control elements that have the readonly attribute set,
>>>>| and to which the readonly attribute applies (thus radio buttons will
>>>>| never match this, regardless of the value of the attribute), as well
>>>>| as elements defined by this specification that are not form controls
>>>>| (namely form, label, datalist, option, optgroup, and fieldset
>>>>| elements).
>>>>
>>>>  First of all, he shouldn't mention "elements...that are not form 
>>>>controls" in the first place, because he's saying that they can be 
>>>>specifically selected by :read-only when the whole point should have 
>>>>been to eliminate anything that might conflict with CSS3-UI, and 
>>>>obviously if we change CSS3-UI to use the XForms definition of 
>>>>:read-only, this will conflict.
>>>
>>>Note that the text above was reviewed by the editor of the CSS3 UI spec 
>>>and given the all-clear.
>>
>>Of course he gave it the all clear. He's the one who wrote the disputed 
>>portion of the spec in the first place.
> 
> Which disupted section of which spec?

For CSS:
   http://www.w3.org/TR/2004/CR-css3-ui-20040511/#pseudo-ro-rw

For WF2:
   http://whatwg.org/specs/web-forms/current-work/#relation
(Continue reading)

Permalink | Reply | 7 comments |
headers
Anne van Kesteren | 1 Aug 2005 13:31
Picon

comment on editors and :read-write

Danial Glazman asked me to e-mail this to the list:

<glazou>   beaufour: I suppose all elements in a document edited by the
           editor become :read-write?
<beaufour> glazou: well, that's my best guess too... but I do not have
           a clue about how the editor works...
<glazou>   I think it should probably _not_ apply
<glazou>   because otherwise editing could become hell
<glazou>   imagine *:read-write { border: red dotted 1px }
<glazou>   that should not apply in the editor
<glazou>   see my point?

This should probably go to www-style eventually as well.

IMHO it makes some sense. Especially when :read-write etc. come in wide use. In
an editor you want to edit what you see and what will be the end result, if you
add :read-write you are thinking about the end result, not editing environment.

See also: <https://bugzilla.mozilla.org/show_bug.cgi?id=302188#c17>

Kind regards,

Anne

--

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
Permalink | Reply | 1 comment |
headers
Anne van Kesteren | 1 Aug 2005 13:59
Picon

[wf2] no value selected for type=range

It is not 100% clear to me what no value selected means for type=range. Say we
have this example:

# <form method="get">
#  <p><input type="range" value="200">
#  <p><input type="submit">
# </form>

As the MIN and MAX attributes have default values it is clear that the specified
value is out or range. Should it fall back to its initial value which is defined
to  be equivalent to the value of the MIN attribute or should something else
happen?

See <http://whatwg.org/specs/web-forms/current-work/#no-value> and some
paragraphs above and below that.

# By default, all of these new types (except range), just like the types from
# HTML4, must have no value selected unless a default value in a valid format
# is provided using the value  attribute. If a value is specified but it is
# not in a format that is valid for the type (where the valid types are the
# same as the valid submission types described above) then the defaultValue
# DOM attribute has the specified value, but the control is left with no
# value selected.

If type=range is also excluded from the second sentence, which is the part that
is unclear to me, the user interface should probably show the specified value
as well although it is out of range and make it clear that it is not
submitable?

--

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
Anne van Kesteren | 1 Aug 2005 17:49
Picon

Re: [wf2] no value selected for type=range

Quoting Anne van Kesteren <fora@...>:
> Should it fall back to its initial value which is defined
> to be equivalent to the value of the MIN attribute or should something else
> happen?

Found this:

# For value attributes that are invalid according to the min, max, step,
# maxlength, etc, attributes
#    The control must be set to that value. The form will not submit with that
# value, though. If the control cannot be set to that value (for example, a
# range control cannot represent values outside its range) then the value must
# be clamped to the nearest value that can be represented by the 
control. (This
# situation can also arise if these attributes are dynamically updated using
# the DOM.)

So it should clip to the nearest value. Which is basically MAX or MIN 
depending
on which has overflow.

--

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
Permalink | Reply | 0 comments |
headers
Matthew Raymond | 2 Aug 2005 17:54
Picon
Favicon

[WA1] Idea: meta attribute

   I've been noticing that a lot of metadata gets repeated in the web
pages. For instance, the copyright notice you have at the bottom of a
web page may be repeated in a <meta> element...

In <head>:
| <meta name="copyright"
|  content="Copyright &copy; 2005 by Matthew Raymond.">

In <body>:
| <div id="copyright">
|   Copyright &copy; 2005 by Matthew Raymond.
| </div>

   This is a pain, because it increases the size of the document
unnecessarily. So, I was thinking that it would be nice if we could just
say that a specific element contains metadata of a particular type.
Here's and example:

| <div meta="copyright">
|   Copyright &copy; 2005 by Matthew Raymond.
| </div>

   The value of the |meta| attribute above is the same as that of the
|name| attribute in a <meta> element. So the above markup creates the
same metadata as following <meta> element:

| <meta name="copyright"
|  content="Copyright &copy; 2005 by Matthew Raymond.">

   When you have multiple elements with the same |meta| value, you get a
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dean Edwards | 3 Aug 2005 23:03

Pattern Hint

I know this has been suggested before, and was rejected, but I would 
quite like to see a "pattern hint" attribute added to Web Forms 2.0. 
With more complex input controls we should spare a thought for the poor 
user.

I've been trying to think of ways to feedback pattern mismatch help info 
but end up scratching my head. How do I explain in generic terms a 
"pattern mismatch"? Some help text needs to be supplied by the interface 
to help in scenarios where pattern mismatches occur. Otherwise the user 
is going to be flummoxed.

The blockage before was discoverability. I can see a way round that. A 
simple hint button/icon next to the control will do. A hint button would 
be considered part of the browser's chrome and would not be stylable by 
CSS. Failing that, the hint text can at least be fed back to the user on 
validation failure.

A "hint" attribute could probably be extended to other control types 
too. However, I'm not sure that this is necessary as most input types 
imply the kind of data they need. Text patterns are the exception, they 
can be complex but meaningful. Some help would be good.

-dean
Permalink | Reply | 2 comments |
headers
dolphinling | 4 Aug 2005 05:47
Picon

Re: comment on editors and :read-write

Anne van Kesteren wrote:
> Danial Glazman asked me to e-mail this to the list:
> 
> <glazou>   beaufour: I suppose all elements in a document edited by the
>            editor become :read-write?
> <beaufour> glazou: well, that's my best guess too... but I do not have
>            a clue about how the editor works...
> <glazou>   I think it should probably _not_ apply
> <glazou>   because otherwise editing could become hell
> <glazou>   imagine *:read-write { border: red dotted 1px }
> <glazou>   that should not apply in the editor
> <glazou>   see my point?
> 
> This should probably go to www-style eventually as well.
> 
> IMHO it makes some sense. Especially when :read-write etc. come in wide use. In
> an editor you want to edit what you see and what will be the end result, if you
> add :read-write you are thinking about the end result, not editing environment.
> 
> See also: <https://bugzilla.mozilla.org/show_bug.cgi?id=302188#c17>
> 
> Kind regards,
> 
> Anne

FWIW, I agree.
--

-- 
dolphinling
<http://dolphinling.net/>
(Continue reading)

Permalink | Reply | 0 comments |
headers
dolphinling | 4 Aug 2005 05:56
Picon

Re: [WF2] Readonly and default pseudoclass matching

Matthew Raymond wrote:
>    So, when am I going to need to disable a single read-only control
> independently of other controls? Not seeing a use case here.

A little contrived, perhaps, but license agreements are usually 
read-only. If you had a case of "do X _or_ accept this license 
agreement", and the person chose to do X, the license agreement would be 
disabled.
--

-- 
dolphinling
<http://dolphinling.net/>
Permalink | Reply | 1 comment |

Gmane