W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2004

[whatwg] Re: Various attributes

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 23 Jun 2004 15:55:57 +0000 (UTC)
Message-ID: <Pine.LNX.4.58.0406231551020.30035@dhalsim.dreamhost.com>
On Thu, 17 Jun 2004, Malcolm Rowe wrote:
>>
>> Oh, right, can Pattern not work on fields that can contain newlines
>> then, I misunderstood, I thought it could, that's not so useful then.
>
> Ah, ok, good point, and good question: I'm not sure. If it can, you're right
> that '.*' won't be sufficient to match the start. I'd imagine that most
> fields would be single-line, though, so this might not be such a problem.

Patterns can be used on multiline fields, if you really want to use them
there -- although I don't know of a use case.

On those fields, to match everything, then something, then everything, you
would have to do something like:

   pattern="[\s\S]* something [\s\S]*"

The spec has a note to that effect. It's ugly, but I do not think it will
be remotely common enough to be optimising for it at the expense of the
other cases.


> As a table:
>
>                      Designer expects pattern to be:
>                      | a whole-field pattern (common?) | a standard regexp
> ---------------------+---------------------------------+--------------------
> No implicit wrapping | Appears to succeed, but doesn't | OK
> ---------------------+---------------------------------+--------------------
> Implicit wrapping    | OK                              | Fails immediately
> ---------------------+---------------------------------+--------------------

That (and the fact that the majority of people seemed to be in favour of
the whole-field pattern model) convinces me that we should stick with the
current text.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 23 June 2004 08:55:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:34 UTC