input: add pattern attr

[voischev]

Для валидации форм решили попробовать возможности hmtl5, но блок их не поддерживает http://www.the-art-of-web.com/html/html5-form-validation/

[veged]

could you make PR? it doesn't looks hard

[veged]

see https://github.com/bem/bem-components/pull/963/files

[narqo]

@veged don't you think, that it would be weird to have a public attribute, that wouldn't work across all of supported browsers? For me it's like to have "position" field in popup, that would work only in Chrome.

I don't believe in this kind of API. This kind of "assumptions" should be implemented on the project level.

@voischev may be you could add something like the code below to your project:

block('input')(
  def()(function() {
    applyNext({ _ctx : this.ctx });
  }),
  elem('control').attrs()(function() {
    var attrs = applyNext();
    attrs.pattern = this._ctx.attrs.pattern;
    return attrs;
  })
)

[veged]

@narqo ouch, miss that cross browser nuance :-/ +1 for yours project-level variant

[veged]

but from another point of view — what gonna be wrong if we add pattern attr for browsers where it doesn't supported? seems like they will be ignore it, so we have auto fallback ;-)

[narqo]

So we would have a part of API, which we doesn't control. How would we document it (and guarantee it) for our internal "enterprise" users?

[dfilatov]

+1 to @narqo We should guarantee functionality of every supported attribute.

[voischev]

:+1: I think I need to support inline method of writing attrs. Now this is not possible, without appending libs components

html provides such an opportunity

[veged]

@voischev Yeah, you are right!

But I can't imagine good API for that. Right now __control element creates internally and doesn't have representation in BEMJSON. However some attributes for __control taken from input object.

If we add some field like controlAttrs it will be ugly (especially with another control attrs which sets from root of object). We also can say that input field attrs stay for __control attributes and lost possibility to set attributes for block node itself.

Any other variants?

[aristov]

302

[veged]

close in favour of possibility to redefine it on own level (see #1053)